导读

这本书有点厉害，看完读懂了，就大致知道构建类微博的亿级社交平台的大部分秘密。

微博及Twitter这两大社交平台都重度依赖Redis来承载海量用户访问。

本书通过实例介绍如何使用 Redis来设计一个社交系统，以及如何扩展 Redis

让其能够承载上亿用户的访问规模。

但是这其实是其中一部分内容，也就是第8章到第10章的实例。

在第6章里面讲到了如何构建通用的redis组件，这些组件可以在其他地方重用，这个很厉害.

举例而言，作为轻量级的消息队列，可以在相对短的消息（小于10K）使用情况下面，性能远远超越了RabbitMQ.

第7章里面的实例是广告服务器和职位匹配服务器，这些都是很实用的，尤其广告服务器的代码就是一个生产中使用的产品，极具参考价值。

第11章的Lua脚本扩展方法，扩展redis服务器的功能，还有一个副作用是可以提高性能。

比如你原先要传输一大堆的指令给redis服务器，现在只要告诉redis服务器一个lua脚本名称就可以了，节约了大量的传输带宽。

下面再讲讲几个专题

扩展读性能

假定我们用 Redis来构建一个与微博具有相同特性和功能的社交类网站，他的其中一个特性就是允许用户查看自己的profile页和个人首页信息流，每当用户来访问时，程序就会从信息流里面获取大约30条内容。

因为一台专门负责获取信息流的Redis服务器每秒至少可以同时为 3,000 ～ 10,000 个用户获取信息流消息，所以这一操作对于规模较小的社交网站来说并不会造成什么问题。

但是对于规模更大的社交网站来说，程序每秒需要获取的信息流消息数量将远远超过单台 Redis 服务器所能处理的上限，因此我们必须想办法提升 Redis 每秒能够获取的信息流消息数量。

下图展示了Redis主从服务器的多层次结构，关键在于master负责写入，slave负责读，这就是业界推崇的读写分离。

还有一个关键是主从服务器之间传输带宽对于复制速度的影响，下面还会讲到。

（图：一个 Redis 主从复制树示例，树的最底层由 9 个从服务器组成，而中间层则由 3 个复制辅助服务器组成）

相对于写扩展来说，其实读扩展相对来说还是比较容易的，对于编程对于数据的副作用也是比较小。

扩展写性能和内存容量

随着被缓存的数据越来越多，当数据没办法被存储到单台机器上面的时候，我们就需要想办法把数据分割存储到由多台机器组成的集群里面。

扩展写容量

尽管这一节中讨论的是如何使用分片来增加可用内存的总数量，但是这些方法同样可以在一台Redis 服务器的写性能到达极限的时候，提升Redis 的写吞吐量。

在对写性能进行扩展之前，首先需要确认我们是否已经用尽了一切办法去降低内存占用，并且是否已经尽可能地减少了需要写入的数据量。

对自己编写的所有方法进行了检查，尽可能地减少程序需要读取的数据量。

将无关的功能迁移至其他服务器。

在对 Redis 进行写入之前，尝试在本地内存中对将要写入的数据进行聚合计算，这一做法可以应用于所有分析方法和统计计算方法。

使用锁去替换可能会给速度带来限制的 WATCH/MULTI/EXEC 事务，或者使用 Lua 脚本。

在使用 AOF 持久化的情况下，机器的硬盘必须将程序写入的所有数据都存储起来，这需要花费一定的时间。对于 400,000 个短命令来说，硬盘每秒可能只需要写入几MB 的数据；但是对于 100,000个长度为1KB 的命令来说，硬盘每秒将需要写入100MB 的数据。

如果用尽了一切方法去降低内存占用，尽可能地提高性能之后，问题仍然未能解决，那么就能够说明我们确实已经遇到了只使用单台机器带来的瓶颈，这给出了一个标志-需要把数据分片到多台机器上面。

为应对增长进行预先的分片

在为应对未来可能出现的流量增长，对系统进行预先的分片的时候，可能就会陷入这样一种处境：目前来说拥有的数据实在太少了，按照预先分片的方法计算出来的机器数量去存储这些数据，只会得不偿失。为了能够如常对数据进行分割，我们可以在单台机器上面运行多个Redis服务器，并且每个服务器用作一个分片。

注意，在同一台机器上面去运行多个Redis服务器的时候，请记得让每个服务器都监听不同的端口，并确保所有服务器写入的是不同的快照文件或AOF文件。

主从复制的带宽问题

书中还提到了，在主从redis服务器架构里面，如果数据量比较大，就会很吃带宽，如果带宽不够，还会带来一个副作用，没有发出的write指令被累加起来使得master的内存被很大的消耗。

解决这个传输带宽问题，有好几个思路，第一种是上面提到的使用lua脚本替代那些pipeline包含的多个指令；

第二种思路，使用自带压缩的ssh隧道来作为redis client和redis server之间的通道，有个公司说采用了ssh以后主从服务器之间的复制所需带宽从21Mbit 降低为 1.8Mbit（http://mng.bz/2ivv）

$ ssh -C -L 6280:localhost:6379 $MASTER_REDIS

$ redis-cli slaveof localhost:6280

别忘了设置ssh的压缩属性

ssh_config(~/.ssh/ssh_configor/etc/ssh/ssh_config)

Compression yes    CompressionLevel 5

压缩对cpu一定的消耗，但是基本上可以忽略不计，redis服务器本身对于cpu消耗是很少的。

使用Redis Sentinel

Redis官方推荐的高可用性(HA)解决方案

Redis Sentinel可以配合Redis的复制功能使用，并对下线的主服务器进行故障转移。Redis Sentinel是运行在特殊模式下的 Redis 服务器，但它的行为和一般的 Redis服务器并不相同。

一般来说，使用Redis Sentinel的目的就是为了向主服务器属下的从服务器提供自动故障转移服务。Master当掉以后，Sentinel服务器重新选择一个Slave作为新的Master，然后通知其他Slave这种变更。一个最佳实践是，Sentinel服务器作为中介，Redis客户端全部到该Sentinel服务器查询Master Redis的地址信息，Master更换以后，Sentinel自然会提供一个新的Master地址，客户端甚至不用关注是否发生了什么故障。但是我在想，要是这个Sentinel也发生故障怎么办？Sentinel的负载比较小，一般不会出问题吧。

更深入了解Redis Sentinel可以阅读http://redis.io/topics/sentinel