《拒绝最终一致性的脏读陷阱： Umem-cache 强一致性实现原理》
原文：consistency.rst缓存一致性是 Umem-cache 最关键的特性，缓存协议和集群的设计方案都是围绕着它展开的。缓存一致性能减少软件开发中的复杂性，因为你不需要担心过时的数据，这是最终一致性做不到的。
选择缓存一致性是有代价的：我们牺牲了可用性。也就是一旦 Umem-cache 挂掉，即使你的其他服务依旧完好，整个系统也无法工作。但是不必担心，我们有基于 raft 共识算法的集群解决方案，它可以提供很高的容错能力。
缓存协议
我们的缓存协议提供了 GetOrSet 和 Delete 两个命令，是的， 我们把 Get 和 Set 合并了。
缓存一致性的实现是靠在数据库中的 Key 更新完成的瞬间，以下事件确保发生：
[*]没有任何连接正在读取 Key
[*]所有在此之前读到 Key 且未完成 Set 的连接都已被关闭
[*]Umem-cache 中不存在该 Key
下面我将详细说明：
缓存命中
缓存命中时，Umem-cache 直接返回数据。
但是如果 key 因为正在 set 而被锁住了，该 get 操作会给该锁设置上过期时间，并排队等待 value 。另外，如果锁到期了，持有锁的连接会被关闭，并把锁转交给排队中的下一个连接。
::
客户端 Umem-cache 数据库 get key|------------------------->| | 1. 等待锁释放 返回 value ||<-------------------------|缓存未命中
当缓存未命中时，我们会锁住 key ，然后尝试 set ，其他 get 请求会排队等待，这种机制是为了防止缓存击穿。
你可能发现了，Umem-cache 不响应 Set ，这让我们省掉了一次网络传输。因为它大概率会成功，就算失败也不是什么大事。
::
客户端 Umem-cache 数据库 get key|------------------------->| | 1. 锁住 key 返回 miss ||<-------------------------| get key|--------------------------------------------------->| | 2. 等待读锁 返回 value ||<---------------------------------------------------||------------------------->| 3. set value 4. 释放 key 的锁更新或删除
事务和锁能保证数据库在更新完成时，该 key 未被缓存，且不在缓存的路上。
将第 4 步放在事务的最后是最佳实践，因为如果该 key 已被缓存，那么在此之前，所有的 Get 都会命中，而不是在队列中等待。
::
客户端 Umem-cache 数据库|-------------------------------------------------->| 1. 开启事务 | 2. 获取 key 的写锁|<--------------------------------------------------| 3. 更新或删除 key 删除 key|-------------------->| 4. 删除 key 或关闭持有 key 锁的连接|<--------------------||-------------------------------------------------->| 5. 提交事务集群
集群的负载均衡靠的是客户端散列，在集群模式下，每个 key 都携带了 8 字节的版本号前缀，这个版本号与它要散列到的成员的版本号一致。一旦 key 散列到的成员发生变化，对应成员的版本号会增长，这个版本号是由 Raft 共识协议来维护的，并且我们保证了所有成员的版本号都不同。所以一旦 key 散列到的成员发生变化，旧成员上的 key 就会因为版本号的变化自动失效，这个机制就保证了同一时间不可能有两个成员上存在相同的有效的 key 。
集群也有一个版本号，这个版本号可以用来快速判断集群是否发生变化，这个版本号也是由 Raft 共识协议来维护的。每次集群成员变更或者成员可用状态变更都会导致集群版本号增长。所以集群版本号的增长也代表着集群中 Key 的散列分布发生了变化。
我们的集群协议提供了 Leader ，Authority 和 Cluster 三个命令，每一个缓存命令都会向集群获取执行授权，这个授权通过 Authority 命令来执行，Authority 命令会返回当前集群的版本号。
下面是客户端实现流程：
::
----- |开始| ----- | v ------------------------- |随机选择服务器查询领导者信息|<---------- ------------------------- | | | v | ---------------------------------- | |向领导者查询集群信息，得到 version V1| | ---------------------------------- | | | --------------------------- | | 并行 | | v v | ---------------------------------- ----- | |向领导者请求认证权威，得到 version V2| |缓存| | ---------------------------------- ----- | | | | --------------------------- | | | v | / \ | / \ | / \ | /V1==V2 \ | \ /--------否--------- \ / \ / \ / | 是 | v ----- |结束| -----
⚠️内容来自互联网，如有侵权请点击反馈！侵权投诉 把get/set合成GetOrSet还靠关闭连接来保证一致性，有点激进啊。缓存一挂整个系统陪葬，除非raft切换足够快。想问下主节点故障时切过去大概要多久，这期间客户端是直接报错还是阻塞等？
[这只是一个小尾巴] 一直讨论类似缓存一致性问题，直到我选择了更简单的方式你的这个实现方式太重度了，以至于无法验证正确性我的方式很简单：依赖 db/redis 的一致性简单说：无论是 insert/update/delete ，都认为是变更，version + 1cdc 监听事件变更：（ version, object ）变成一个事件cache:object_key_$id : {version: $version, objcet...}redis 更新，update if version > current简单高效，不阻塞更新过程，允许瞬间 cache 差异---你这套机制，除非高一致性才需要但是，到了这一级别的高一致性，简单依赖 db 就好了，没必要这么复杂 一直讨论类似缓存一致性问题，直到我选择了更简单的方式你的这个实现方式太重度了，以至于无法验证正确性我的方式很简单：依赖 db/redis 的一致性简单说：无论是 insert/update/delete ，都认为是变更，version + 1cdc 监听事件变更：（ version, object ）变成一个事件cache:object_key_$id : {version: $version, objcet...}redis 更新，update if version > current简单高效，不阻塞更新过程，允许瞬间 cache 差异---你这套机制，除非高一致性才需要但是，到了这一级别的高一致性，简单依赖 db 就好了，没必要这么复杂 @cloudzhou 确实 深有同感 @LDa 他这里还有一个非常难解决的问题，就是 update 然后其实隐含多个 cache 更新比如 update order set xxx where yyy ，导致多个 order 修改这时候，触发的不是单个 order 更新，是批量更新cdc + 版本号，解决这个问题 一直讨论类似缓存一致性问题，直到我选择了更简单的方式你的这个实现方式太重度了，以至于无法验证正确性我的方式很简单：依赖 db/redis 的一致性简单说：无论是 insert/update/delete ，都认为是变更，version + 1cdc 监听事件变更：（ version, object ）变成一个事件cache:object_key_$id : {version: $version, objcet...}redis 更新，update if version > current简单高效，不阻塞更新过程，允许瞬间 cache 差异---你这套机制，除非高一致性才需要但是，到了这一级别的高一致性，简单依赖 db 就好了，没必要这么复杂 @cloudzhou 你说的多个 cache 更新的问题是在我流程里是不存在的，因为第一步就是 select for update 去拿写锁，所有要改的都已经查出来了。至于你说的前面一套方案，你还要考虑很多问题，第一你的业务和 cdc 是需要对 key 的格式有约定的，这一点是需要同步的；第二数据库需要维护 version 字段，业务上 insert/update/delete 这些操作你都需要额外得去维护 version 字段，万一忘记更新就会变成永久的不一致，连最终一致性都达不到。其实这些都不是问题，只要你能接受短暂的不一致，只要你够小心。我的观点是如果缓存能直接提供强一致性，你不需要考虑额外的东西，业务的实现会变得简单，也不需要部署额外的 cdc ，考虑 cdc 的可用性。 @cloudzhou 另外在部署集群的情况下多个 cache 更新，redis 连最终一致性都保证不了，因为 redis 不支持跨节点的 lua 脚本 把 Get 和 Set 合并成 GetOrSet 挺巧的，省了并发窗口。但锁过期后排队那段怎么处理？锁都过期了值还没写进来，等待的请求是直接报错还是继续等，这直接关系到牺牲的可用性到底兜不兜得住。
[论坛助手]
页:
[1]