这是情况。拥有数百万用户的网站。每个用户的页面都有一个消息部分。任何人都可以访问用户的页面，他们可以在其中留言或查看最后 100 条消息。
消息是带有一些额外元数据的短文本文件。每条消息都必须永久存储，唯一必须实时快速的是消息更新和阅读（人们将其用作聊天）。将经常阅读一些消息以检查更改。定期归档旧消息（大于 100 条）是可以的，但它们必须是可访问的。
目前都在一个大数据库表中，阅读消息列表和发送更多更新的人之间的争用正在成为一个问题。
如果您必须重新构建系统，您会使用什么存储机制/缓存？这里可以使用什么样的计算机科学学习？（例如集合、列表访问等）
一个简单的解决方案可能是对数据进行非规范化，并将预先计算的聚合存储在单独的表中，例如 MESSAGE_COUNTS 表，其中包含用户 ID 列和消息计数列。当主消息表更新时，重新计算聚合。
它只是将瓶颈从一个地方转移到另一个地方，但它可能会将其转移到负担较少的地方。
一些一般性的想法，而不是特定于任何特定技术：
按用户 ID 对数据进行分区。这个想法是您可以将用户空间统一划分为大小大致相同的不同分区。您可以使用适当的散列函数跨分区划分用户。最终，每个分区都属于单独的机器。但是，即使在同一台机器上的不同表/数据库上，这也会消除一些争用。分区限制了争用，并为将来“线性”扩展打开了大门。这也有助于负载分配和横向扩展。
在选择散列函数对记录进行分区时，请寻找一个在添加/删除分区时最小化必须移动的记录数量的函数。
像许多其他应用程序一样，我们可以假设该服务的使用遵循幂律曲线：很少有用户页面导致大量流量，然后是长尾。缓存方案可以利用这一点。曲线越陡峭，缓存就越有效。给定短消息，如果每页显示 100 条消息，并且每条消息平均为 100 字节，则在 1GB 的 RAM 缓存中可以容纳大约 100,000 个首页。这些缓存的页面可以延迟写入数据库。在 1000 万用户中，有 100,000 人在努力发挥作用。
对 Web 服务器进行分区，可能使用相同的散列方案。这使您可以保持单独的 RAM 缓存而不会发生争用。潜在的好处是随着用户数量的增长而增加缓存大小。
如果适合您的环境，确保新消息最终写入数据库的一种方法是在将它们放入 RAM 缓存之后立即将它们放入持久消息队列中。队列不会发生争用，并有助于确保消息在机器故障时不会丢失。