为了回答这个问题特意去注册了一个帐号，结果发现还得等7000秒才能回复...

首先，如果你的系统还没有一个DAL层，那么是时候去实现一个了。否则下面的内容也没必要看了。

短期解决方案，你的MYSQL使用肯定有问题，不到百万级的数据不太可能搞不定。从表结构，语句，配置，连接池等等方面入手优化。就算你的业务再复杂，应该也可以应付得来。如果实在不行，必须要用REDIS，那就自己写一个一致性HASH，REDIS设置成多节点负载。这个实现快，也十分有效果，从KEY的数量上来看，区区65万X5也不算很大。 我之前记得100万KEY在REDIS中使用的内存也不过70M这样而已，当然，这和存的VALUE也有关系。现在商用服务器随便32G 64G内存，对数据结构做一些优化，REDIS也作一些优化BLABLA，用REDIS存储完全没有压力。注意这个阶段因为是对REDIS直接当数据库用的，所以要特别注意它的数据持久化和恢复方案。

如果从预期上来看数据会随业务发展有暴发式增长的话，那就需要考虑冷热数据交替的架构，简单讲就是加缓存结构，其它分库分表之类的就不提了。 可以把上述短期解决方案中的REDIS集群直接用做缓存，不会改变的冷数据扔到MYSQL数据库中去。请求先到缓存层，取不到再到数据库去取，同时把数据放置在REDIS中。这里大概的实现可以这样做，所有在REDIS中的数据全都设置相应的过期时间，每次访问重置过期时间。在每个REDIS MASTER节点拖的SLAVE节点上作RDB，把生成的RDB文件离线定时解析，把其中过期时间小于某值的所有数据同步到MYSQL中。

终极解决方案，如果你的数据量和访问量大到没边了。以上的REDIS集群不管怎么扩容，连正常的查询修改操作也完全COVER不住时。首先要恭喜你的应用比较牛B了现在。现在要做的事情有很多，可能需要有多级缓存，CDN扩展，甚至业务上要作一些妥协等等。从框架上来讲，大概的思路就是读写分离以及深化分离。 比如说，你前两步做的REDIS集群只用作读操作了，所有写操作只记录在简要日志中。写操作的请求过程中，不在数据持久层或缓存层作修改操作。然后你有离线的系统TAIL所有写操作的简要日志，把这些操作离线同步到数据持久层和缓存层。不过这样写操作因为只是记录了日志，写操作完成后有一段时间查询请求过来时是访问不到该修改的。这段时间的长短与你的离线日志流处理系统的性能相关。

REDIS 的RDB解析可以用REDIS RDB TOOLS， 用PYTHON写的，对过期时间的处理可能需要一些自定义的修改，PYTHON新手就可以胜任。
日志流的处理可以用卡夫卡，可靠，安全，速度快。