最新数据库与缓存一致性的解决方案
数据库和缓存的数据一致性问题一直是老生常谈的话题了，它不仅在面试中十分常见，而且在实际开发中也是需要加以考量的因素。借着难得的空暇时光（其实是晚上不太想写代码），笔者今天想和大家简单讨论一下，数据库和缓存的数据一致性问题，以及如何避免or解决数据库和缓存的数据不一致的问题。 为什么要引入缓存？ 在我们的后端系统没有引入缓存之前，我们的后端系统大致来讲应该是类似于这样的模型。 应用服务器中的数据库驱动通过网络I/O向数据库发增删改查操作的请求，数据库通过硬盘I/O在硬盘读/写相应数据之后，再通过网络I/O返回给应用服务器的数据库驱动，然后完成后续的业务操作。 这个模型在请求量较小的时候，是行得通的。但是当请求量变大，就会出现性能问题，而这个性能问题的瓶颈就出在硬盘I/O上。 我们都知道，内存的读写速度大于磁盘的读写速度，那么我们可以考虑将一些数据放到内存中，这样就能有效加快整体的响应速度。此时的模型应当是这样的。 对于缓存，我们有以下几个疑问： 对于缓存中存放的数据，是存放全部数据，还是存放热点数据？ 假如数据库中的数据发生了更新/删除，缓存中对应的数据要怎么处理？ 最简单的思路 ...
找到了就业的极佳选择
那就是去麦当劳做汉堡 @zerkos16 #mcdonalds: viande10-1 cuisson🥩#tiktok#fyp ♬ Storytelling - Adriel （需要打开vpn后才能观看） 今天面了腾讯ieg，感觉自己确实应该不太适合写代码，更适合去麦当劳烤汉堡肉
简谈设计模式之责任链模式
责任链模式, 又称职责链模式, 为了避免将请求发送者和多个请求处理者耦合在一起, 将所有请求的处理者通过前一对象记住其下一个对象的引用而连成一条链, 当有请求发送时, 可将请求沿着这条链传递, 直到有对象处理它为止 责任链模式结构 抽象处理者: 定义一个处理请求的接口, 包含一个抽象处理方法和一个后继连接 具体处理者: 实现抽象处理者的处理方法, 判断是否能够处理本次请求, 如果可以处理请求则处理, 否则将该请求转发给它的后继者 客户类: 创建处理链, 并向链头的的处理者提交请求, 不关心处理细节和请求的传递过程 责任链模式实现 假设现在有以下场景, 现在需要开发一个请假系统, 请一天的假需要组长同意, 1~3天的假需要部门经理同意, 3~7天的假需要总经理同意 // 请求public class LeaveRequest { private String name; private int num; private String content; public LeaveRequest(String name, int num, Str ...
面对Yonagi's Sekai被墙，我的一点应对措施
昨天晚上，试着用手机访问了一下本站，发现不开梯子已经访问不上了，我大概意识到，可能是我的网站被伟大的GFW给ban掉了。我的运营商是中国移动，目前来看是无法直接访问的，必须得用一些科技，这可能是运营商对Github旗下的一系列域名进行了DNS污染所致（当然，即使同样用的移动网，不同地方的访问情况应该也有差别，但总体上大差不差） 本站的主站和镜像站，用站长之家测速工具测速结果如下： 综上，我强烈建议访客都访问镜像站……主站是托管在Github的，能否访问很大程度上受当地运营商是否对Github域名进行了DNS污染，而镜像站是托管在Netlify上面的，就目前来看，Netlify的访问速度还是要比Github的要快一点的。 如果访客有VPN的话，我强烈建议开了VPN再来访问，速度会比不开VPN要好很多
简谈设计模式之命令模式
命令模式将一个请求封装为一个对象, 使得发出请求的责任和执行请求的责任分隔开, 这样两者之间通过命令对象进行沟通, 这样方便将命令对象进行存储, 传递, 调用, 增加与管理 命令模式结构 抽象命令类: 定义命令的接口, 声明执行命令的方法 具体命令类: 具体命令, 实现命令接口; 通常会持有接收者, 并调用接收者的功能来完成命令要执行的操作 实现者: 接收者, 真正执行命令的对象. 任何类都可以成为一个接收者, 只要它能够实现命令要求实现的功能 请求者: 要求命令对象执行请求, 通常持有命令对象. 它是使用命令对象的入口 命令模式实现 我们假设有一家餐厅, 客户需要向服务员点单, 服务员再把点单信息提交给厨师. // 订单类public class Order { private int tableNum; private Map<String, Integer> foodDir = new HashMap<>(); public void setTableNum(int tableNum) { ...
简谈设计模式之策略模式
策略模式定义了一系列算法, 并将每个算法封装起来, 使它们可以相互替换, 算法的变化不会影响到使用算法的用户. 策略模式结构 抽象策略类: 定义所有支持的算法的公共接口 具体策略类: 实现策略接口的具体算法 上下文类: 持有一个策略类的引用, 通过策略接口调用具体策略类的方法 策略模式实现 假设一家商店在不同的节日推出不同的促销活动, 由推销员将活动展示给客户. public interface Strategy { void show();}public class StrategyA extends Strategy { void show() { System.out.println("买一送一"); }}public class StrategyB extends Strategy { void show() { System.out.println("满100减20"); }} ...
简谈设计模式之模板方法模式
模板方法模式定义了一个算法的骨架, 并允许子类在不改变算法结构的情况下重新定义算法的某些步骤. 通过这种方式, 实现了代码的复用与拓展 模板方法模式结构 抽象类: 定义了算法的骨架, 包含一个模板方法. 这个模板方法定义了算法的步骤, 并且某些步骤可以调用抽象方法或钩子方法, 允许子类自行实现 具体类: 继承自抽象类, 实现抽象方法或钩子方法, 以完成算法的具体步骤 模板方法模式实现 以下是一个简单的模板方法模式实现. 我们以制作咖啡和茶为例, 以饮料类作为抽象类, 而咖啡和茶作为具体类 abstract class Beverage { // 模板方法, 定义了算法步骤 public final void perpareBeverage() { boilWater(); brew(); pourInCup(); if (customerWantCondiments()) { addCondiments(); } } ...
客户端秘因
有后选后，无后选前，无后无前，算法也甜，条件允许，无脑后端，前途无量，预定高管，其次前端，需求频繁，温饱有余，人上人难，算法数据，收入可观，最好硕博，高端饭碗，测试开发，也可一战，随手一点，月入过万，走投无路，回家种田，日出日落，生活美满，鬼迷心窍，来客户端，表面繁荣，实则内卷，工作清闲，面试火箭，不到三年，全部玩完，65在后，绿帽在前，苦口婆心，金玉良言，奉劝诸位，擦亮双眼，有则改之，无则加勉。 —— 牛客用户 客户端劝退第一人 我为什么突然想要难得再写一次生活类的blog，主要还是因为今天发生的一点事。前段时间boss上面海投，大小厂都投了一轮，也有一些公司找我要了简历，包括大厂。今天字节跳动的HR小姐姐打电话过来了，说我的简历初审通过，可以进入流程，邀请我参加面试，岗位是抖音直播的客户端开发。我自己确实不怎么懂客户端这块领域，遂表达歉意之后婉拒了面试。今天吃完晚饭，闲的没事刷牛客，就刷到了牛客用户“客户端劝退第二人”的一篇推文了，光看用户名就知道是劝退客户端的，但因为今天正好接到了字节的客户端开发的面试邀约，所以还是点开看了下。大意就是客户端属于是校招容易社招难，前端后端都能 ...
Java最强本地缓存——Caffeine
缓存（Cache）在计算机中无处不在。缓存本质上是一种用空间换时间的手段——通过将数据存储在更快的存储媒介上，减少响应的时间，使得下一次访问这些数据的时候能够获得加速的效果。从缓存类型来看，缓存还分为 本地缓存 和 分布式缓存 两种类型。分布式缓存（如 Redis 集群）除了要解决数据读取效率问题外，还要解决集群环境下的数据不一致问题。本文将简单地介绍一种高性能的本地缓存库——Caffeine，以及Caffeine 的使用、驱逐策略、刷新策略，以及如何在 SpringBoot 中使用 Caffeine Caffeine 简介 Caffeine 是基于Java 1.8的高性能本地缓存库，由 Guava 演变而来，它的性能比Guava也更好，官方声称在基准测试中， Caffeine 的缓存命中率已经接近于最优值，且 Caffeine 的内存占用情况也优于 Guava 实际上，Caffeine 这种本地缓存和 ConcurrentHashMap 很像——都支持并发，都支持 O(1) 时间复杂度的存取。两者的主要区别在于： ConcurrentHashMap 会存储所有存入的数据，且数据移除 ...
简谈设计模式之享元模式
享元模式通过共享相似或相同的对象来减少内存使用和提高性能. 核心思想是把对象的状态分为内部状态和外部状态, 其中内部状态可以共享, 外部状态则由客户端来负责. 通过共享内部状态可以减少需要创建的对象数量, 从而节约内存 享元模式结构 享元接口: 定义对象的接口, 通过这个接口, 享元可以接收并作用于外部状态 具体享元类: 实现享元接口, 并存储可以共享的内部状态 非共享享元类: 不需要共享的享元接口子类. 因为享元接口共享了具体的享元对象, 因此可以不需要 享元工厂: 用于管理和创建享元对象 享元模式实现 假设我们有一个需要绘制许多字符的文本编辑器, 每个字符都有特定的样式（例如字体、大小、颜色等）. 如果为每个字符都创建一个对象, 这将导致大量的内存消耗. 我们可以使用享元模式来共享相同样式的字符对象, 从而减少内存使用 import java.util.HashMap;import java.util.Map;// 享元接口interface Character { void display(int x, int y);}// 具体享元类class C ...
简谈设计模式之外观模式
外观模式是一种结构性设计模式, 通过为复杂的子系统提供一个统一的接口, 使得子系统更容易使用. 外观模式结构 外观: 提供一个高层接口, 供客户使用, 它知道哪些子系统负责处理请求, 并将客户的请求委派给适当的子系统 子系统类: 实现子系统的功能, 处理由外观指派的任务 外观模式实现 假设有一个复杂的家庭影院系统, 包括DVD, 投影仪, 音响, 灯光等系统, 可以通过外观模式来模拟这个系统的实现 class DVDPlayer { public void on() { System.out.println("DVD Player is on"); } public void play(String movie) { System.out.println("Playing " + movie); } public void off() { System.out.println("DVD ...
简谈设计模式之组合模式
组合模式是一种结构型设计模式, 允许将对象组合成树形结构表示 “部分-整体” 的层次结构. 组合模式使得客户端对单个对象和组合对象的使用具有一致性 组合模式结构 抽象组件: 定义了组合对象和叶子对象的接口, 包括添加, 删除子组件以及其他共享的行为 叶子节点: 代表组合中的叶子对象, 它没有子节点, 定义了对象的基本行为 组合节点: 定义有子组件的那些对象, 存储子组件, 并实现抽象组件中的相关操作 组合模式实现 假设要实现一个文件系统, 包括文件和目录, 目录包含文件和子目录, 可以用组合模式来实现这个系统 // 抽象组件abstract class FileSystemComponent { public void add(FileSystemComponent component) { throw new UnsupportedOperationException(); } public void remove(FileSystemComponent component) { throw n ...
简谈设计模式之桥接模式
桥接模式是一种结构型设计模式, 它将抽象部分和它的实现部分分离, 使它们可以独立变化. 这意味着可以改变它的抽象和它的实现, 而不会相互影响 桥接模式结构 抽象 (Abstraction): 定义抽象类, 并包含一个对实现类对象的引用 拓展抽象 (Refined Abstraction): 拓展抽象类, 通过组合的方式调用实现类的方法 实现 (Implementor): 定义实现类的接口, 但不具体实现, 它仅提供一个接口, 供具体实现类进行实现 具体实现 (ConcreteImplementor): 具体实现Implementor接口 桥接模式实现 假设有一个画图程序, 需要渲染不同图形, 同时还需要在不同操作系统上渲染, 可以使用桥接模式来实现这个程序 // Implementorinterface DrawingAPI { void drawCircle(double x, double y, double radius);}// ConcreteImplementorAclass DrawingAPI1 implements DrawingAPI ...
简谈设计模式之装饰者模式
装饰者模式是一种结构型设计模式, 它允许在不改变对象自身的情况下动态地为对象添加行为和职责. 装饰者模式通过创建一个装饰者类来包裹原始类, 从而增强或修改其功能 装饰者模式结构 组件接口: 定义了对象的公共操作的接口或抽象类, 定义了对象的公共操作 具体组件: 具体的定义类, 实现组件接口 装饰者: 这是抽象类, 实现组件接口, 并持有一个组件对象的引用, 它通过组合方式将客户端的请求转发给被装饰的对象, 具体的装饰者类将从这个抽象修饰者继承并拓展其功能 具体装饰者: 装饰者模式的核心部分, 具体装饰者类从装饰者类继承, 并通过创建新的方法或重写组件方法来增强或改变被装饰对象的行为 装饰者模式实现 interface Component { void request();}class ConcreteComponent implements Component { @Override public void request() { System.out.println("ConcreteCompone ...
用Synthesizer V翻唱了一首曲子……
前几天嫖了一个盗版的Synthesizer V，装了几个声库，随便扒了一首曲子来玩一玩 影片现在已经发布在Youtube和Bilibili，欢迎来捧场
简谈设计模式之适配器模式
适配器模式是结构型设计模式之一, 用于将一个类的接口转换成客户期望的另一个接口. 通过使用适配器模式, 原本由于接口不兼容而无法一起工作的类可以协同工作 适配器模式通常有两种实现方式 类适配器模式 (Class Adapter Pattern）: 使用继承来实现适配器。 **对象适配器模式 (Object Adapter Pattern) **: 使用组合来实现适配器。 适配器模式结构 目标接口: 当前系统业务所期待的接口, 可以是抽象类也可以是接口 适配者类: 它是被访问和适配的现存组件库中的组件接口 适配器类: 它是一个转换器, 通过继承或引用适配者的对象, 把适配者接口转换成目标接口, 让客户按目标接口的格式访问适配者 适配器模式实现 类适配器模式 类适配器模式通过继承目标接口和被适配类, 实现适配功能 // 目标接口interface Target { void request();}// 被适配者类class Adaptee { void specificRequest() { System.out ...