看之前redis设计与实现、还有网上解析的文章，大部分都聚焦在redis的数据结构的实现，其实也了解一下redis的事件设计，更好的了解redis的处理过程

redis 集群

工作模式

通过分片进行数据管理，提供复制和故障转移

去中心化，分槽16634一个，每个节点负责部分槽位数据，每个集群是对等的，通过gossip协议交互集群信息，最后每个节点保存其他节点的slots

什么是gossip协议

在一个处于有界网络的集群里，如果每个节点都随机与其他节点交换特定信息，经过足够长的时间后，集群各个节点对该份信息的认知终将收敛到一致。

这里的“特定信息”一般就是指集群状态、各节点的状态以及其他元数据等。Gossip协议是完全符合 BASE 原则，可以用在任何要求最终一致性的领域，比如分布式存储和注册中心。另外，它可以很方便地实现弹性集群，允许节点随时上下线，提供快捷的失败检测和动态负载均衡等。

此外，Gossip 协议的最大的好处是，即使集群节点的数量增加，每个节点的负载也不会增加很多，几乎是恒定的。这就允许 Redis Cluster 或者 Consul 集群管理的节点规模能横向扩展到数千个。

故障协议

Redis 集群节点采用 Gossip 协议来广播自己的状态以及自己对整个集群认知的改变。比如一个节点发现某个节点失联了 (PFail)，它会将这条信息向整个集群广播，其它节点也就可以收到这点失联信息。
如果一个节点收到了某个节点失联的数量 (PFail Count) 已经达到了集群的大多数，就可以标记该节点为确定下线状态 (Fail)，然后向整个集群广播，强迫其它节点也接收该节点已经下线的事实，并立即对该失联节点进行主从切换。
当一个 Slave 发现自己的主节点进入已下线状态后，从节点将开始对下线的主节点进行故障转移。

1、从下线的 Master 及节点的 Slave 节点列表选择一个节点成为新主节点。
2、新主节点会撤销所有对已下线主节点的 slot 指派，并将这些 slots 指派给自己。
3、新的主节点向集群广播一条 PONG 消息，这条 PONG 消息可以让集群中的其他节点立即知道这个节点已经由从节点变成了主节点，并且这个主节点已经接管了原本由已下线节点负责处理的槽。
4、新的主节点开始接收处理槽有关的命令请求，故障转移完成。

检测过程

1. Redis Cluster 中的节点会定期检查已经发送 PING 消息的接收方节点是否在规定时间 ( cluster-node-timeout ) 内返回了 PONG 消息，如果没有则会将其标记为疑似下线状态，也就是 PFAIL 状态
2. 将疑似下线状态的信息传递给其他节点，其他节点将该节点也标记为疑似下线
3. 随着时间的推移，如果节点十 (举个例子) 也因为 PONG 超时而认为节点二疑似下线了，并且发现自己维护的节点二的 clusterNode 的 fail_reports 中有半数以上的主节点数量的未过时的将节点二标记为 PFAIL 状态报告日志，那么节点十将会把节点二将被标记为已下线 FAIL 状态，并且节点十会立刻向集群其他节点广播主节点二已经下线的 FAIL 消息，所有收到 FAIL 消息的节点都会立即将节点二状态标记为已下线
4. 如果超过 cluster-node-timeout *2 的时间，这个报告就会被忽略掉，让节点二又恢复成正常状态。

短链系统的设计

1. 本质上是生成映射关系，一个长链对应到一个短链，那就看短链的生成方式是什么

• hash，存在hash碰撞的问题，解决方法一般是重复hash，找到一个不碰撞的值，查库的话总是存在瓶颈啊，可以用布隆过滤器优化，查看生成的短链是否在数据库表记录中，用布隆过滤器的好处占用内存少
• 可以使用生成id的方式，一般都是用分布式id生成
  简单的自增主键
  redis
  snowflake
  • 时钟回退问题，生成id有毫秒时间戳，所以可能导致某个生成的id会重复
  • • 进程重启+时间回拨 加入时钟版本号，进程重启的时候
  • • 引入zk，解决workid和时间戳
  • • 非技术手段，一般硬件支持NTP，但也会造成秒级回退，一般是运维场景解决
      uuid

怎么设计一个红包系统？春晚抢红包和日常抢红包

redis hotkey是什么？有哪些影响？怎么解决
slot 模式，热key集中在某几台机器
监控 - 热key发现
优化 - 一般是二级缓存(本地缓存)
多级key -
大key是什么？有哪些影响？怎么解决
大文件断点续传？

mysql 半同步复制退化到异步复制？
ack超时的时候，强一致场景不能容忍，解决办法，调大半同步的超时时间
写扩散读扩散是什么？
一般用于feed流项目，比如朋友圈，好友关系关注之类的，数据写一份还是写多份

腾讯抽奖系统学习

抽奖系统作为 QQ 红包的核心系统，在承接用户抽奖请求，按设计合理的几率完成抽奖操作，将抽奖结果安全落地保存，并顺利发货等过程中，起到了关键作用。面对海量抽奖请求，如何及时作出响应，是抽奖系统面临的难题。

1）在接入层采用一致性 Hash 算法：同一用户的抽奖请求只会转发到相同的抽奖系统处理 ;
2）抽奖系统采用缓存机制：在加快抽奖过程的同时也减少了对存储层的访问压力；
3）奖品配额机制：平滑抽奖过程，各类奖品按比例有序抽中；
4）流水和对账机制：保证抽奖数据最终无差错发放到用户账户中。

缓存，很重要，如何提升缓存命中率，一般使用一致性hash算法

流水系统 记账对账

双buffer 无锁切换

一写一读的场景，可以实现目标，属于空间换时间