这种场景应如何设计缓存？求思路

显示全部楼层 · 2015-3-5 06:00:15

有一张主表是任务表，里面记载了当前需要人处理的所有任务，大约3000万记录，然后还有一些关联的保存任务明细的表。主要逻辑就是每当一条新任务需要处理，就插入一条记录到此表，每当一条任务已经处理完成，就标记状态为"已完成“。

每秒有几百个用户对这个表以及关联表进行查询，最常见的查询是用户A用自己id查询状态为”未完成“的任务，看自己名下有多少待处理任务，然后逐条处理。也有一些其他条件，如以任务开始时间，过期时间，任务的关键字等等，现在数据库压力主要在处理这些查询上面，cpu占用超过80%。

为缓解数据库压力，我想加一些缓存机制，但因为此任务表每秒都会有几十条新任务被插入，也有几十条任务被完成。用户每次刷新都希望获得最新的任务数量情况，如果将这些任务缓存，无论多短的过期时间都无法满足实时查询的要求。
像这种实时性强的系统，如果遇到性能瓶颈，该如何设计缓存呢？或者有没有其他不用大改数据结构可以解决问题的思路？
（任务表过期数据会定时清理，但仅活跃数据已经有3000万或者更多了）

千问 · 2015-3-5 06:00:15

mv？？

千问 · 2015-3-5 06:00:15

3000w，可以考虑分区表
OO说的应该可以吧，对MV增量刷新

千问 · 2015-3-5 06:00:15

(用户ID,状态)应该有索引吧？几百个用户同时查询应该构不成压力。应该把负载最大的查询拿出来看看有什么可以改善的。

千问 · 2015-3-5 06:00:15

可以试试内存数据库