近日把memcached的相关协议看了下，把我的数据前端又重新梳理了一遍。开始琢磨着如何把我memcached应用到项目中，对于我自己仿造的轮子有点失去信心了。。。如果是对于一个web项目，memcached有很大的发挥空间，特别是对一些静态页面的缓存，如图片，文件，视频等，不需要数据的同步，也不会存在从cache中获得脏数据的可能。但是对于我们一个游戏项目，如果按照memcached的协议去做缓存，玩家第一次登录的时候，从db获取，并保存在cache中，以后该玩家的数据就直接从cache中获取。但不同于web服务，玩家在游戏过程中，身上携带的数据不停的变化，这样就会要求数据必须从服务器内存同步到数据前端的cache,然后前端再通过一种机制存入硬盘的dbms。 如果说这种方案实施成功的话，当然会大大的减轻数据库的压力，memcached对内存管理非常的给力，又可以分布式管理，甚至LRU机制让下线的玩家依然可以把数据放在cache中。这些对于我来说诱惑很大，当然这些都是理论上，其实理论上可以多数都是操蛋的。 下面说说问题在哪里，先假设玩家的数据是这样的：
玩家第一次登录的时候把这些信息全部获取了，在该玩家下线的时候，u_exp增加了，但是u_money没变，假设该时，我做一次数据同步，那么我犯愁了，玩家这么多数据，我该更新哪条数据呢？全部做一次数据覆盖应该不是一个好的设计，因为有可能db没有提供一个覆盖所有数据的存储过程，只针对了每个数据段的更新提供存储过程。这里有一个比较次一点的方案就是玩家在每次更新数据的时候，就让cache去通知db也更新一次，这时cache就是把玩家的操作及时的转达给了db,不用为日后的同步做任何tag。这样下来db的写操作还是没有减少，但是读操作大大的减少了，这也不失为一种折中方案。最近准备试试这个方案，看下高峰期db的效率能提升多少。
posted on 2012-01-06 15:59 zuhd 阅读(2545) 评论(8) 编辑 收藏 引用 所属分类: server
加个bool isUpdate;的标志不就完了么 回复 更多评论
我现在就是这么做的，从心理上一直觉得它很丑陋 回复 更多评论
针对数据库编程，需要注意网络通信开销。 1、更新一个字段和更新20个字段，对于数据库来说开销大头在网络通信上，除非一个IP包装不下，否者考虑更新一个或多个字段总体来说没有任何意义。 2、对于持久化，尽量使用批量接口，数据库会很HIGH的。 回复 更多评论
@zzzdev 你所指的网络开销是指带宽？一般服务器和数据库的通讯都是在局域网内，不存在什么开销，你说的批量接口，不懂耶 回复 更多评论
用SP可以节约一点带宽。不过对于更新数据来说，对数据库的消耗确实是大的。而如果只是查询，那并不存在任何问题。网络开销基本上不是问题，现在部署上多半都是同局域网的，千兆网卡，甚至光纤，很难造成太大的影响。数据库主要IO开销还是在硬盘上，特别是更新数据。用memcached，主要也就是减轻磁盘IO的消耗，缓存在内存中，减少对磁盘的操作。像MySQL这样级别的数据库，可以把数据规模降低，比如分表这种做法。当然，这需要数据规模达到一定程度。所以我现在还没有分表。数据库还能承受。我现在头疼两个东西：1.批量更新；2.日志的增长。日志倒还好，勤快点备份清理就好。批量更新，可以缓存数据到内存当中，以期减少写入频率，但是，始终还是要写入的，这个负载最终还是无可避免的。 回复 更多评论
@杨粼波 你要是想减少写操作，就模拟rpg的做法，玩家下线时统一保存数据，或是定时保存数据，日志嘛有钱的话单独用一台服务器做。 其实频繁的读操作也能把mysql拖的疲惫不堪，关系数据库快要被淘汰了 回复 更多评论
再怎么减少，还是有操作的，只能说是尽量的减少操作量。因为现在的磁盘型硬盘io操作还是非常非常慢的。这种优化是非常收益可观的。其实我现在也是采用的定时保存，开了数据库的连接池。我有经常查看数据库的消耗，多半都是消耗在了批量更新上。现在来看，还是可以承受的。如果你的MySQL能被查询所拖垮，那你可以考虑下：能否减少查询的次数？如果不可行，那是否应该要去分表了？现在的确KV型的NoSQL数据库兴起了，但是就我直觉来说，很长时间内关系型的SQL数据库是不大可能被淘汰的。 回复 更多评论
Powered by: C++博客 Copyright © zuhd