缓存为什么能提高性能？

为什么memcached的性能比mysql高？

首要因素是memcached的数据都是位于内存中，mysql的数据可能是位于磁盘里。从IO速度来说，内存IO比磁盘IO会快几个数量级，memcached也就比mysql性能更高。架构和性能优化做到后面，会发现最终限制性能的是硬件瓶颈。例如nginx做静态webserver时，出口流量往往能达到网卡的最大值或出口带宽的最大值。mysql是个性能还不错的db，但它的数据持久化在磁盘上，自然就受限于磁盘IO速度。

mysql也是有缓存的，但大多数场景下觉得还是不够用，这就涉及到次要因素——针对具体业务特征做优化。mysql支持完全的增删查改SQL操作，还得支持where条件组合，这种复杂性让mysql的缓存机制有较大挑战，不像memcached这种key-value类型的操作一定是点查询，所以mysql的缓存机制不如memcached那么简单有效。总结一点就是，性能、通用性、成本三者难以同时满足。在成本一定的情况下，专用的高效，通用的低效，ttserver/redis/mangodb也都符合这个原则。如何同时满足性能和通用性呢？那自然就是提高成本，最简单的方案是mysql+固态硬盘。

针对具体业务特征做优化，有很多我们耳熟能详的其他表述方法：因地制宜、因时制宜、具体问题具体分析、特例化等等。它确实是我们适用于人生、事业、技术的一个原则，是个好东西。经验多的优势就是能因地制宜、因时制宜的去分析解决问题。出现问题后，我们一般会先扛住再优化，必要时会拿空间换时间，或者拿时间换空间。

“空间换时间”看起来有点高深，其实只是个包装，举个例子就明白了。在《数据层的演进(上)》中，当访问量增加时，我们使用更多的机器横向扩容，性能得以提升，这个就是拿更多的机器（空间）来换用户更快的访问速度（时间）。

SNS查询

随着社交网络的普及，查询好友动态的需求更常见了。这个功能怎么实现呢？最简单粗暴的做法是先查询我的好友有哪些，然后再依次查询好友的动态，接着把这些好友动态聚合起来按时间排序，最后存入缓存中备用。上流的做法是，开发一个专用的server来实现这个功能，对外只用提供一个简单的接口。这个server内部还会把“依次查询好友的动态”变成“并行查询好友的动态”，最后再聚合，这样能提高速度，有点MapReduce的感觉。

数据一致性问题

业务server如果有多个（横向扩容），并且使用memcached这种公用缓存，那么需要处理好数据一致性问题。如果A和B两个业务server“同时”都从memcached缓存里读取了player信息，修改后用set方式写回到缓存时，那么先做的修改会被后做的修改覆盖掉，因为set方式是直接覆盖，不检查其他内容。为解决这个问题，可以采用cas方式更新缓存。

cas方式的思路是这样的，读数据时会获得数据的seq，cas更新数据时，先检查cas里提交的seq和缓存里的seq是否一致，一致才会更新数据并把seq+1。上述A和B读数据得到相同的seq，前一个cas更新成功后seq会变，后一个cas就会失败。这时需要业务server自行处理好cas更新失败的情况。

但这个又会衍生另一个问题，如果业务server的某个操作需要有5次数据更新操作，假如最后的cas操作可能失败，那么前面4次数据更新操作就麻烦了，是回滚，还是把最后的cas再操作一次，或者把这个失败记录在案就不管了？不管是哪种都有麻烦，不够完美，需要按业务实际的情况来做分析。

业务server内部缓存

为了避免上述数据一致性问题，在游戏后台设计中，还有一种做法是由gamesvr自己在内部管理缓存。这种做法的好处是缓存专用，不用考虑其他gamesvr修改缓存导致的数据不一致性问题。需要注意的问题是，数据只能在一个gamesvr里访问，如果需要访问其他gamesvr管理的数据，就通过proxysvr来中转请求。对于现在分区分服模式的游戏，只要没有太重的逻辑计算，用C++开发的gamesvr完全能一个server进程搞定一个区8000人同时在线（现实中一个区的同时在线也很难达到8000）。这样就是在gamesvr里搞定所有事情，不考虑互斥，不考虑数据一致性。

备份策略

线上业务如果没做数据备份，皮鞭滴蜡的惩罚都是轻的。重要数据采用每天全量备份+binlog增量备份+slave实时同步。这些都是常见技术方案，不啰嗦了。