高性能服务器架构思路「不仅是思路」

上面说了运行时静态的缓存清理，现在说说运行时变化的缓存数据。在服务器程序运行期间，如果用户和服务器之间的交互，导致了缓存的数据产生了变化，就是所谓“运行时变化缓存”。比如我们玩网络游戏，登录之后的角色数据就会从数据库里读出来，进入服务器的缓存(可能是堆内存或者memcached、共享内存)，在我们不断进行游戏操作的时候，对应的角色数据就会产生修改的操作，这种缓存数据就是“运行时变化的缓存”。这种运行时变化的数据，有读和写两个方面的清理问题：由于缓存的数据会变化，如果另外一个进程从数据库读你的角色数据，就会发现和当前游戏里的数据不一致;如果服务器进程突然结束了，你在游戏里升级，或者捡道具的数据可能会从内存缓存中消失，导致你白忙活了半天，这就是没有回写(缓存写操作的清理)导致的问题。这种情况在电子商务领域也很常见，最典型的就是火车票网上购买的系统，火车票数据缓存在内存必须有合适的清理机制，否则让两个买了同一张票就麻烦了，但如果不缓存，大量用户同时抢票，服务器也应对不过来。因此在运行时变化的数据缓存，应该有一些特别的缓存清理策略。

在实际运行业务中，运行变化的数据往往是根据使用用户的增多而增多的，因此首先要考虑的问题，就是缓存空间不够的可能性。我们不太可能把全部数据都放到缓存的空间里，也不可能清理缓存的时候就全部数据一起清理，所以我们一般要对数据进行分割，这种分割的策略常见的有两种：一种是按重要级来分割，一种是按使用部分分割。

先举例说说“按重要级分割”，在网络游戏中，同样是角色的数据，有些数据的变化可能会每次修改都立刻回写到数据库(清理写缓存)，其他一些数据的变化会延迟一段时间，甚至有些数据直到角色退出游戏才回写，如玩家的等级变化(升级了)，武器装备的获得和消耗，这些玩家非常看重的数据，基本上会立刻回写，这些就是所谓最重要的缓存数据。而玩家的经验值变化、当前HP、MP的变化，就会延迟一段时间才写，因为就算丢失了缓存，玩家也不会太过关注。最后有些比如玩家在房间(地区)里的X/Y坐标，对话聊天的记录，可能会退出时回写，甚至不回写。这个例子说的是“写缓存”的清理，下面说说“读缓存”的按重要级分割清理。

假如我们写一个网店系统，里面容纳了很多产品，这些产品有一些会被用户频繁检索到，比较热销，而另外一些商品则没那么热销。热销的商品的余额、销量、评价都会比较频繁的变化，而滞销的商品则变化很少。所以我们在设计的时候，就应该按照不同商品的访问频繁程度，来决定缓存哪些商品的数据。我们在设计缓存的结构时，就应该构建一个可以统计缓存读写次数的指标，如果有些数据的读写频率过低，或者空闲(没有人读、写缓存)时间超长，缓存应该主动清理掉这些数据，以便其他新的数据能进入缓存。这种策略也叫做“冷热交换”策略。实现“冷热交换”的策略时，关键是要定义一个合理的冷热统计算法。一些固定的指标和算法，往往并不能很好的应对不同硬件、不同网络情况下的变化，所以现在人们普遍会用一些动态的算法，如Redis就采用了5种，他们是：

1.根据过期时间，清理最长时间没用过的

2.根据过期时间，清理即将过期的

3.根据过期时间，任意清理一个

4.无论是否过期，随机清理

5.无论是否过期，根据LRU原则清理：所谓LRU，就是Least Recently Used，最近最久未使用过。这个原则的思想是：如果一个数据在最近一段时间没有被访问到，那么在将来他被访问的可能性也很小。LRU是在操作系统中很常见的一种原则，比如内存的页面置换算法(也包括FIFO,LFU等)，对于LRU的实现，还是非常有技巧的，但是本文就不详细去说明如何实现，留待大家上网搜索“LRU”关键字学习。

数据缓存的清理策略其实远不止上面所说的这些，要用好缓存这个武器，就要仔细研究需要缓存的数据特征，他们的读写分布，数据之中的差别。然后最大化的利用业务领域的知识，来设计最合理的缓存清理策略。这个世界上不存在万能的优化缓存清理策略，只存在针对业务领域最优化的策略，这需要我们程序员深入理解业务领域，去发现数据背后的规律。

分布

分布策略的概念

任何的服务器的性能都是有极限的，面对海量的互联网访问需求，是不可能单靠一台服务器或者一个CPU来承担的。所以我们一般都会在运行时架构设计之初，就考虑如何能利用多个CPU、多台服务器来分担负载，这就是所谓分布的策略。分布式的服务器概念很简单，但是实现起来却比较复杂。因为我们写的程序，往往都是以一个CPU，一块内存为基础来设计的，所以要让多个程序同时运行，并且协调运作，这需要更多的底层工作。

（编辑：威海站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!