一致性

1.使用缓存的场景 缓存是提高系统读性能的常用技术，尤其对于读多写少的应用场景，使用缓存可以极大的提高系统的性能 例子：查询用户的存款： select money from user where uid = YYY; 为了优化该查询功能，我们可以在缓存中建立uid->money的键值对。 减少数据库的查询压力。 2. 读操作流程 目前数据库和缓存中都有存储数据，当读取数据的时候，流程如下。 1）先读取缓存是否存在数据(uid->money)。如果缓存中有数据返回结果。 2）如果缓存中没有数据，则从数据库中读取数据。 介绍一个概念： 缓存命中率：缓存命中数/总缓存访问数。 3. 写操作流程 在介绍写操作流程之前，先讨论两个问题 问题一：淘汰缓存还是更新缓存？ 淘汰缓存：数据只会写入数据库，不会写入缓存，只会把数据淘汰掉。 更新缓存：数据不但写入数据库，还会写入缓存。 问题二：先写缓存还是先写数据库？ 由于对缓存的更新和数据库的更新无法保证事务性操作。一定涉及到哪个先做，哪个后做的问题，我们的原则是采取对业务影响小的策略。下面是四种不同的组合策略 由此可见第四种策略的影响最小，只会造成一次查询缓存miss而已。那么当查询缓存miss的时候，我们该怎么办？很简单，查询数据库，然后将数据库的内容更新到缓存中。可能有人会问第四种策略，如果一上来淘汰缓存就失败了怎么办，当然是直接返回即可

系列文章 Raft算法赏析 ZooKeeper的一致性算法赏析 Raft对比ZAB协议 1 leader选举 1.1 刚开始所有server启动都是follower状态 然后等待leader或者candidate的RPC请求、或者超时。 上述3种情况处理如下： leader的AppendEntries RPC请求：更新term和leader信息，当前follower再重新重置到follower状态 candidate的RequestVote RPC请求：为candidate进行投票，如果candidate的term比自己的大，则当前follower再重新重置到follower状态 超时：转变为candidate，开始发起选举投票 1.2 candidate收集投票的过程 candidate会为此次状态设置随机超时时间，一旦出现在当前term中大家都没有获取过半投票即split votes，超时时间短的更容易获得过半投票。 candidate会向所有的server发送RequestVote RPC请求，请求参数见下面的官方图 上面对参数都说明的很清楚了，我们来重点说说图中所说的这段话 If votedFor is null or candidateId, and candidate’s log is at least as up-to-date as receiver’s log,

3 月，跳不动了？>>> 1 kafka基础 本篇文章讨论的kafka版本是目前最新版 0.10.1.0。 1.1 kafka种的KafkaController 所有broker会通过ZooKeeper选举出一个作为KafkaController，来负责： 监控所有broker的存活，以及向他们发送相关的执行命令。 分区的状态维护：负责分区的新增、下线等，分区副本的leader选举 副本的状态维护：负责副本的新增、下线等 1.2 kafka分区中的基本概念 每个分区可以有多个副本，分散在不同的broker上。 leader副本：被KafkaController选举出来的，作为该分区的leader 其他follower副本：其他副本都作为follower副本 isr列表：简单描述就是，"跟得上"leader的副本列表（包含leader）,最开始是所有副本。这里的跟得上是指 replica.lag.time.max.ms：在0.9.0.0之前表示follower如果在此时间间隔内没有向leader发送fetch请求，则该follower就会被剔除isr列表，在0.9.0.0之后表示如果该follower在此时间间隔内一直没有追上过leader的所有消息，则该follower就会被剔除isr列表 replica.lag.max.messages（0.9.0.0版本中已被废除）