主程的晋升攻略(9):数据层的演进(下)

缓存为什么能提高性能?

为什么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实时同步。这些都是常见技术方案,不啰嗦了。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
©️2022 CSDN 皮肤主题:大白 设计师:CSDN官方博客 返回首页
评论 2

打赏作者

thinkry

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值