我们的移动应用跟踪用户事件（事件可以有多种类型）
每个报告用户事件的移动设备都可以检索它。
我想写信给Redis和Mysql。
当用户请求时：
1. Find on Redis
2. If not on Redis find on Mysql
3. Return the value
4. Keep Redis modified in case value wasnt existed.
5. set expiry policy to each key on redis to avoid out of mem.
问题：
1. Reads: If many users at once requesting information which not existed at Redis mysql going to be overloaded with Reads (latency).
2. Writes: I am going to have lots of writes into Mysql since every event going to be written to both datasources.
事实：
1. Expecting 10m concurrect users which writes and reads.
2. Need to serv each request with max latency of one second.
3. expecting to have couple of thousands requests per sec.
这种机制的任何解决方案都有良好的qos？
3. Is that in any way Lambda architecture solution ?
谢谢。
答案 0 :(得分：0)
很抱歉，但是这些问题（复杂的）很少在这里有一个现成的答案。太多未知数。您的预算是多少，硬件有多少。由于1000万客户端同时使用您的服务，您的问题是关于硬件，而不是软件。
这里没有关于几个重要要求的任何说法：
如果您有10,000,000个并发用户，这本身就是个问题。但是如果你有很多阅读，那就不像看起来那么糟糕了。在这种情况下，您应该注意mysql中的正确索引。还要购买具有大量RAM的服务器，以便至少将索引数据保存在RAM中。因此，一台服务器可以在1秒内保持3000-5000个并发选择查询，而不会出现任何延迟要求问题（我们的统计项目之一在4年普通硬件上每台服务器最多可容纳7,000个选择rps）。
如果你有很多写作 - 一切都变得更加复杂。一致性成为主要问题。
如果一致性很重要 - 请到商店购买带有SSD驱动器和现代CPU的新服务器。不要忘记尽可能多地购买RAM。为什么？如果你有很多写请求，你的sql server会在每次写入时重建索引。并且您不能不使用索引，因为您的读取请求不会保留延迟要求。在一致性下，我的意思是 - 如果你写了一些东西，你应该在1秒钟内完成这项工作，如果你在写完后立即阅读这些数据，你将在1秒钟内得到实际的书面信息。
你的问题1：
读取：如果许多用户同时请求Redis mysql中不存在的信息将会超载Reads（延迟）。
或众所周知的“缓存未命中”问题。它只有一些解决方案 - 横向扩展（购买更多硬件）或预先缓存。在这种情况下，预处理可以在至少3种情况下完成：
他们每个人都妥协：
写道：由于每个事件都要写入两个数据源，因此我将对Mysql进行大量写入。
再次提出妥协。很多写的都是硬件。因此，购买更多或使用队列进行挂起写入。因此可用性与一致性再次一致。
事件跟踪意味着（通常）您可以接近实时但不能实时返回数据。例如，更新磁盘上的数据（mysql）需要1-10秒的延迟，从而为写/读服务请求保留1秒的延迟。 因此，它是用于数据验证的1/2/3（或其他）技术的组合：