mjunz的博客

不针对单节点进行写入重试，而是循环写所有节点，只关注写入的库存数量，所以才采用了渐进式写入的方法。一.读多写多，如果使用Redis作主存储，先写Redis再写MySQL，那么如果写多个key，Redis写一半key，系统就宕机，可利用lua保证事务性。如果缓存中不存在，那么就首先添加分布式锁，然后再查询MySQL，查询到数据后便将数据更新到缓存，最后返回。合并扣减的时候，每当对一个节点扣减完该节点可以扣的库存后，也就是扣减该节点的缓存库存值和传入待扣减库存值的最小值之后，就返回还剩需要继续扣减的库存值。

于是第一个线程写缓存时就把缓存里的最新数据给覆盖了，从而出现数据库里的是新数据，但缓存里的是旧数据，产生了不一致。因为每次数据发生变更都更新缓存，但缓存中的数据不一定会被马上读取，这会导致缓存中存放了很多不常访问的数据，浪费缓存资源。用户数据是典型读多写少的数据，可能0.01%是写，99.99%是读，所以进行用户注册和信息更新的操作是极少的。以MySQL为例，当一条数据发生修改时，MySQL就会产生一条变更日志binlog，我们可以订阅这个日志，拿到具体操作的数据，然后再根据这条数据，去删除对应的缓存。

当从服务器对主服务器进行初次复制时，主服务器会将自己的运行ID发送给从服务器，从服务器会保存主服务器的运行ID。如果从服务器之前保存的运行ID和当前连接的主服务器的运行ID相同，则可以尝试执行部分复制，否则主服务器对重服务器执行全量复制。当子进程完成AOF重写工作后，会向父进程发送一个信号，父进程收到该信号后会调用信号处理函数进行如下处理：首先，将AOF重写缓冲区的所有内容写入到新AOF文件中，保持数据一致性。如果是全量复制，那么主服务器需要成为从服务器的客户端，才能将复制缓冲区里的写命令发送给从服务器。

因此，为了防止锁篡改，可以在加锁完成之后对锁进行watch操作，一旦锁发生变化，则终止事务，回滚操作。如果返回的是1，那么说明之前没见过这条数据。

整体上看，Ehcache的使用是相对简单便捷的，提供了完整的各类API接口。需要注意，虽然Ehcache支持磁盘的持久化，但是由于存在两级缓存介质，在一级内存中的缓存如果没有主动刷入磁盘持久化，则在应用异常宕机时，依然会出现缓存数据丢失，为此可以根据需要将缓存刷到磁盘。GuavaCache构建的缓存不会"自动"执行清理和回收工作，也不会在某个缓存项过期后马上清理，也没有诸如此类的清理机制，GuavaCache是在每次进行缓存操作时进行惰性删除：如get()或者put()的时候，判断缓存是否过期。

步骤一：首先需要配置一个crontab定时调度shell脚本，然后该脚本每天凌晨会通过rdbtools⼯具解析Redis的RDB⽂件，接着对解析出的内容进行过滤，把RDB⽂件中的⼤key导出到CSV⽂件。步骤二：使⽤SQL导⼊CSV⽂件到MySQL数据库中，同时使⽤Canal监听MySQL的binlog⽇志。步骤三：Canal会发送增量的大key数据消息到RocketMQ，RocketMQ的消费者系统会对增量的大key数据消息进⾏消费，消息中便会包含⼤key的详情信息。

首先挂机是极其罕见的事件，即便挂了，对于特别热的key，完全不影响。有人会说，把这个间隔拉长。比如一个用户刷子，它在非常频繁地刷接口，一秒刷了500次，而正常用户一秒最多点5次，它已经是非常严重的刷子了，但本地还是判断不出它是不是刷子。与Redis更是毫无关系，核心就是靠Netty连接，Client端送出待测key，然后由各个Worker完成分布式计算，算出热key后就直接推送到Client端，非常轻量级。而如果该key是在本地内存中，读取一个内存中的值，每秒多少万次都是很正常的，不存在数据层的瓶颈。

如果后续需要更改限流配置，则通过application.yml文件中配置的limiter.propertiesPath的⽂件地址，将配置⽂件放在propertiesPath对应的⽂件中，通过limiter配置类LimiterProperties的reloadLimiterProperty()⽅法重新加载配置⽂件，即可实现限流的动态配置。那么当时间到达1:00时，由于时间窗⼝会往右滑动⼀格，所以此时时间窗⼝内的总请求数量⼀共是200个，超过了限定的100个，因此此时能够检测出来触发限流。

合并库存进行扣减时，会对多个库存分片里的库存逐一扣减。如果合并扣减也不成功，则进行库存返还。由于该库存模块可以支持高性能的并发读写，因此需要支持对商品库存进行多分片写入和读取处理(分片一般等于节点)，需要提供单个分片库存不足以扣减时的合并库存功能，以及需要提供操作商品入库时的库存渐进性写入缓存的实现。此时有两种选择Redis节点的方案：可以通过随机的方式选出一个Redis节点来进行库存扣减，也可以通过轮询的方式选出一个Redis节点来进行库存扣减，这里会通过轮询的方式来选择Redis节点去进行库存扣减。

对于购物车或者库存这种读多写多的数据，由于存在大量高并发的写、大量高并发的读，那么我们会把主要数据基于Redis来进行主存储，来实现高性能读写，同时通过异步把数据同步到MySQL进行持久化落库。由于购物车的数据是读多写多的数据，所以会使用缓存来存储主数据，以便能够抗住高并发的写和读，然后进行落库的时候再通过异步来落库。一般来说购物车的主数据存储，是由Redis来实现的，并都优先从Redis中进行购物车的写和读，这时是不会有不一致的问题的。

由于不确定分享贴列表页的访问频率 + 缓存全部分享贴列表数据耗费内存，所以没有必要用户发布完分享贴就马上构建该用户的分享贴列表缓存，以及没有必要构建用户分享贴列表缓存时缓存其所有分享贴列表数据。一个用户发布完分享贴后，可能会分页查询发布出去的分享贴列表，而关注他的其他用户也可能会进入其主页分页查询其发布过的分享贴列表。因此一般会采用延迟构建缓存 + 分页列表惰性缓存的方案：即当有用户分页浏览某用户的分享贴列表时，才会构建分享贴列表缓存，并且查询一页才添加一页的数据进分享贴列表缓存中。

第一个线程写缓存时就把缓存里的最新数据给覆盖了，从而出现数据库里的是新数据，但缓存里的是旧数据，产生了不一致。因为如果出现大量的请求并发读取某个已过期的用户数据缓存时，此时只会有一个线程获取到锁去查库，然后其他大量的线程都只能在串行化排队。因此可以参考AQS的做法，获取不到锁的线程先挂起，第一个释放锁的线程就把这些线程全都唤醒执行并发读缓存。缓存击穿是指缓存中没有但数据库中有的数据(一般是缓存时间到期)，这时由于并发请求特别多，同时读缓存没读到数据，又同时去数据库去取数据。

因为每次数据发生变更都更新缓存，但缓存中的数据不一定会被马上读取，这会导致缓存中存放了很多不常访问的数据，浪费缓存资源。这个问题很好，但思考这样一个问题：如果在执行失败的线程中一直重试，还没等执行成功，此时如果项目重启了，那么这次重试请求也就丢失了，那这条数据就一直不一致了。六.在先更新数据库再删除缓存方案下，读写分离 + 主从库延迟也会导致缓存和数据库不一致，缓解此问题的方案是延迟双删，凭借经验发送延迟消息到队列中延迟删除缓存，同时也要控制主从库延迟，尽可能降低不一致发生的概率。

接着如果一个客户端跟Redis发起连接请求，那么服务器监听套接字就会产生AE_READABLE事件，然后触发连接应答处理器来处理客户端的连接请求，接着创建客户端套接字，并将这个新创建的客户端套接字的AE_READABLE事件与命令请求处理器关联起来。每个节点在汇总针对某个节点的疑似下线报告fail_reports时，都会判断集群里是否过半节点都认为某个节点下线了，如果是则标记某个节点为正式下线状态fail，最后还要把某个节点被标记为正式下线状态的信息同步给其他节点。

当大多数节点都认为主节点不可达时，这些Sentinel节点会选举出一个Sentinel节点来完成自动故障转移的工作，同时会将这个变化实时通知给Redis的应用方，整个过程是自动的，实现了真正的高可用。因为一个Sentinel可以通过分析接收到的某服务器的频道信息来获知其他Sentinel的存在，并通过向某服务器发送频道信息来让其他Sentinel知道自己的存在，所以用户在使用Sentinel的时候并不需要提供各个Sentinel的地址信息，监视同一个主服务器的多个Sentinel可以自动发现对方。

如果Redis内存实例大，页表就会大，fork执行时间就长，阻塞主进程的时间也就长。为了避免执行AOF重写后的命令时造成客户端输入缓冲区溢出，所以AOF重写程序在处理列表、哈希表、集合、有序集合这4种可能会带有多个元素的键时，会先检查键所包含的元素数量。当被监听的套接字准备好执行连接应答(accept)、读取(read)、写入(write)、关闭(close)等操作时，与操作相对应的文件事件就会产生，这时文件事件处理器就会调用套接字之前关联好的事件处理器来处理这些事件。

因为压缩列表比双端链表更节约内存，且在元素较少时，在内存中以连续块方式保存的压缩列表，比起双端链表可以更快地被载入到缓存中。比如从跳跃表的表头结点的第一层出发L1，表头L1会指向第一个结点的指针，到第一个结点的L1会指向第二个结点的指针，定位到第二个结点后，从其L1又可以获取第三个结点的指针，依此类推。当服务器打开了maxmemory选项，且服务器用于回收内存的算法为volatile-lru或allkeys-lru，则当服务器占用的内存数据超了maxmemory，空转时长较高的那部分键会优先释放回收内存。