redis数据库双写一致问题

新浪微博「点赞功能」数据库如何设计的？(messageID,likesCount)来记录每个微博帖子的点赞数。 messageID是微博ID，likeCount是微博点赞数。 然而，这里有两个问题需要解决。 第一个是并发性，第二个是数据量。

微博上的每条帖子都可以同时被很多人点赞，为了确保点赞数准确，likeCount++是一个原子操作，你需要确保这一点。 在您的应用程序中或使用Redis事务实现它（如果Redis具有事务机制或自动增量功能）。 出于性能原因，可能没有必要实现原子操作。 具体原因我就不解释了。

每天产生超过数亿条微博内容，从而产生数亿条新数据（messageID、likedCount）。 这个数据量比较大，建站难度较大。 为了提供高效的服务，需要一个分片功能（也称为分表或分库）将这些schema根据消息ID分布到10个或更多的分片（新浪微博有600个（据说有节点）。 ，如何形成3个节点的分片（有200个分片）。 这使得每个分片仅处理原始请求的十分之一，从而提高服务的性能。

当谈到设计喜欢列表时，想到的一个常见模式是（messageID，userID），但这种设计有一个小问题。 也就是说，依靠大法微博，几十万个点赞就会产生几十万条数据。 这是大量数据，读取速度可能很慢。 因此，使用这样一种schema（messageID、partID、userID），对于多个userID来说，一个messageID可能会同时对应太多的userID。 因此，如果添加一个新的partID并在一个part中存储1,000个userID，则有数十万个userID。 您只需要存储几百条数据。 这样做的另一个好处是，当用户点击查看点赞数时，您一次只能批量读取一个数据，而不是像通常那样显示所有点赞数。 您可以显示有关喜欢您的帖子的人的信息。