一文Get所有Redis性能问题分析手段.docVIP

一文 Get 所有 Redis 性能问题分析手段 刘思宁 匠心零度 Redis 性能的基本面 优化网络延时 警惕执行时间长的操作 优化数据结构、使用正确的算法 考虑操作系统和硬件是否影响性能 考虑持久化带来的开销 使用分布式架构 —— 读写分离、数据分片 后话 参考资料 在一些网络服务的系统中，Redis 的性能，可能是比 MySQL 等硬盘数据库的性能更重要的课题。比如微博，把热点微博[1]，最新的用户关系，都存储在 Redis 中，大量的查询击中 Redis，而不走 MySQL。 那么，针对 Redis 服务，我们能做哪些性能优化呢？或者说，应该避免哪些性能浪费呢？ Redis 性能的基本面 在讨论优化之前，我们需要知道，Redis 服务本身就有一些特性，比如单线程运行。除非修改 Redis 的源代码，不然这些特性，就是我们思考性能优化的基本面。 那么，有哪些 Redis 基本特性需要我们考虑呢？Redis 的项目介绍中概括了它特性： Redis is an in-memory database that persists on disk. The data model is key-value, but many different kind of values are supported. 首先，Redis 使用操作系统提供的虚拟内存来存储数据。而且，这个操作系统一般就是指 Unix。Windows 上也能运行 Redis，但是需要特殊处理。如果你的操作系统使用交换空间，那么 Redis 的数据可能会被实际保存在硬盘上。 其次，Redis 支持持久化，可以把数据保存在硬盘上。很多时候，我们也确实有必要进行持久化来实现备份，数据恢复等需求。但持久化不会凭空发生，它也会占用一部分资源。 第三，Redis 是用 key-value 的方式来读写的，而 value 中又可以是很多不同种类的数据；更进一步，一个数据类型的底层还有被存储为不同的结构。不同的存储结构决定了数据增删改查的复杂度以及性能开销。 最后，在上面的介绍中没有提到的是，Redis 大多数时候是单线程运行[2]的（single-threaded)，即同一时间只占用一个 CPU，只能有一个指令在运行，并行读写是不存在的。很多操作带来的延迟问题，都可以在这里找到答案。 关于最后这个特性，为什么 Redis 是单线程的，却能有很好的性能(根据 Amdahl’s Law，优化耗时占比大的过程，才更有意义)，两句话概括是：Redis 利用了多路 I/O 复用机制[3]，处理客户端请求时，不会阻塞主线程；Redis 单纯执行（大多数指令）一个指令不到?1 微秒[4]，如此，单核 CPU 一秒就能处理 1 百万个指令（大概对应着几十万个请求吧），用不着实现多线程（网络才是瓶颈[5]）。 优化网络延时 Redis 的官方博客在几个地方都说，性能瓶颈更可能是网络[6]，那么我们如何优化网络上的延时呢？ 首先，如果你们使用单机部署（应用服务和 Redis 在同一台机器上）的话，使用 Unix 进程间通讯来请求 Redis 服务，速度比 localhost 局域网（学名 loopback）更快。官方文档[7]是这么说的，想一想，理论上也应该是这样的。 但很多公司的业务规模不是单机部署能支撑的，所以还是得用 TCP。 Redis 客户端和服务器的通讯一般使用 TCP 长链接。如果客户端发送请求后需要等待 Redis 返回结果再发送下一个指令，客户端和 Redis 的多个请求就构成下面的关系： （备注：如果不是你要发送的 key 特别长，一个 TCP 包完全能放下 Redis 指令，所以只画了一个 push 包） 这样这两次请求中，客户端都需要经历一段网络传输时间。 但如果有可能，完全可以使用 multi-key 类的指令来合并请求，比如两个? GET key ?可以用? MGET key1 key2 ?合并。这样在实际通讯中，请求数也减少了，延时自然得到好转。如果不能用 multi-key 指令来合并，比如一个? SET ，一个? GET ?无法合并。怎么办？ Redis 中有至少这样两个方法能合并多个指令到一个 request 中，一个是? MULTI/EXEC ，一个是 script。前者本来是构建 Redis 事务的方法，但确实可以合并多个指令为一个 request，它到通讯过程如下。至于 script，最好利用缓存脚本的 sha1 hash key 来调起脚本，这样通讯量更小。 这样确实更能减少网络传输时间，不是么？但如此以来，就必须要求这个 transaction / script 中涉及的 key 在同一个 node 上，所以要酌情考虑。 如果上面的方法我们都考虑过了