作者回复：提前准备的越多，经验积累的越多，碰到问题时会越从容

作者回复：你好，老铁，我查了下这个归类方式不错，柔性相对的性能更好类似TCC ，刚性类似2pc 与xa

作者回复：你好，这类排行榜可以使用周期的离线计算去计算或者使用redis zset或者队列消息到专用排行服务汇总，或者使用clickhouse类似辅助数据库实时吞吐计算[这个不推荐]

作者回复：你好，LLM的服务QPS目前有些低，如果直接对外服务QPS上万的广告投放有些亏，可以考虑让他生成策略，这样会好一些。最后存储建议redis。微博就是你说的结构，后来全换成了redis。

作者回复：你好，PunkHoo，很高兴收到你的留言，一般来说但凡碰到彻底失联的机房情况的切换都是有损的，对于损失只是大小问题，对于这种单主库情况，最理想情况就是损失几条数据，如果是多主情况下会好一点。我碰到的情况多数是需要人工对比修复一下，不过我们的数据常见都有create_time，update_time相对的修复难度会小很多。 同时，高频率更新的数据是不推荐用这个方式做多机房的。

作者回复：你好，Mr.Tree，很高兴收到你的疑问，事实上大部分交易系统为了保证数据的强一致都是用本地主库去做的，当进行交易的时候跨区域通讯到核心机房去做交易。你的开户行决定了你的数据在哪里做决策，在下一节课你会看到Raft算法，这里会对这个疑问有很大的帮助。

作者回复：你好，林晓威，很高兴收到你的提问，这个算法重点并不是这个payload区，payload这里只是附带的数据，只是为了方便业务使用，事实上这个核心在于签名和过期时间，由于密钥是只有服务端有，所以签名是不能伪造的，如果到子业务这里验证签名是正确的密钥加密的，那么代表token的payload的内容肯定是服务器发放的，传输的用户无法更改，如果更改了就会和签名核对不上，通过这个方式就已经能够保证数据的安全了。至于base64内放的数据普遍是可以公开的信息，如果有不能公开的信息可以再做一层加密后再放入payload

作者回复：你好，夏天，很高兴收到你的提问，第一个问题，单个MySQL是能够达到10w QPS的，这个毋庸置疑，我们确实可以通过多个从库实现这样的设计，但是核心要点在于，我们业务不是所有情况都能优化的这么好的，总是有一些业务需要复杂的场景，拖慢整体的性能，所以从某个角度来看，平均性能和木桶中的短板决定了系统的稳定性和性能。第二个问题Redis在内存中占用的空间比磁盘大这里是有系统特性导致的，这里卖个关子，可以看看我们后续的16篇，会得到答案。

作者回复：你好，老朋友，很高兴再次见到你 第一个问题确实如此，目前是通过保证用户一段时间内只能访问一个机房来减少延迟，并且客户端保存最后更新时间，用这个方式来刺激服务端主动更新过期的缓存 第二个问题，城市主干线断了，可以让其他城市机房接管之前的双活机房工作，但是必须距离很近的两个机房才可以。核心在于同步延迟过大，会出现刚插入的数据查不到的情况，会让业务很难维护。如果有决心做双活，业务层是必须能够有类似raft的支撑才可以

作者回复：你好，徐曙辉，很高兴收到你的再次留言 对于session 方式来说，由于用户每次请求都会读取session cache，客户端本地是不会保存token，所以不存在token内用户头像更新不及时问题。可以说后台系统用session管理用户很方便，因为这个可以做到用户实时管理，当我们禁用用户的时候把session的缓存登陆标志删掉即可。不过这个方式适合少量用户，对于QPS超过10w QPS请求的API则不太适合。 所以使用token方式来签名发给客户端，客户端请求其他子系统的时候，会带上它，子系统只要验证这个token的签名就不需要再去用户中心问一句。所以token使用后，用户中心不会被其他子系统频繁请求，但是也导致token发出去没法再次更改，即使我们用户中心给他拉黑了，其他子系统只认印章，不会过来问问。 同时为了方便token内会保存当前用户一些基础信息，减少其他系统过来询问的次数，这导致，用户更新头像，token没更换，是不会同步更新的 第一个很暴力，但是很有趣～ 第二个方式也很有趣，同时补一个技巧我们可以通过 设定 固定网址 user/用户uid/heaer.jpg方式直接获取用户头像，这样也不用考虑更新问题了

作者回复：你好，7S，很高兴收到你的思考，关于这里有一些特殊的小技巧，如请求时带上一些客户端特征，如：请求更换access_token时，带上的refresh_token的请求 同时 需要特殊的签名，存储在本地的token不用明文保存，与服务端通讯时用特殊协议加密等～

作者回复：你好，贺子，这里面有几点：首先，在 Raft 算法中，为了保证数据的强一致性，Follower 在收到查询请求时会询问 Leader 当前最新的 commit 的 log index。如果这个 log index 大于 Follower 同步的进度，说明 Follower 的本地数据不是最新的。这时候 Follower 会从 Leader 获取最新的数据返回给客户端，以保证数据的一致性，这就是前面提到的如果想要最新的数据。 更进一步提高性能上来讲，Raft 算法也可以采用了等待 Leader commit log index 的机制来保证数据的一致性。Follower 在处理读取请求时，会等待 Leader 提交的日志达到一定的进度后才返回数据。这样可以确保读取的数据是已经提交并被大多数节点接受的数据，从而实现强一致性。 可以说Raft 算法通过两种方式来保证数据的强一致性：Follower 主动向 Leader 查询最新的 commit log index，以及等待 Leader 的 commit log index 达到一定进度后才返回数据。这些机制确保了数据的一致性，但也会带来一定的代价和延迟。 另外关于 TiDB 的支持 index read，这是因为 TiDB 在 Raft 算法的基础上进行了优化和改进，以提高读取性能和并发性。这与 Raft 算法本身保证数据一致性的机制是相辅相成的。