关于redis:Redis-实战-13-扩展-Redis

简介

当数据量增大或者读写申请增多后，一台 Redis 服务器可能没方法再存储所有数据或者解决所有读写申请，那么就须要对 Redis 进行扩大，保障 Redis 在能存储所有数据对状况下，同时能失常解决读写申请。P227

扩大读性能 P227

进步性能的几个路径 P228

• 应用短构造：确保压缩列表的最大长度不会太大

• 依据查问类型抉择构造

  • 不要把列表当作汇合应用
  • 不要获取整个散列，而后再客户端外面进行排序，而应应用有序汇合
• 大体积对象存储前进行压缩：缩小读写所需的网络带宽。比照 lz4, gzip 和 bzip2 等压缩算法，抉择对存储数据压缩成果和性能最好对压缩算法
• 流水线和连接池：复制、解决故障、事务及性能优化 中介绍过流水线

扩大读性能最简略的办法就是增加只读服务器（复制、解决故障、事务及性能优化 中介绍过通过复制 (replication) 让一个 Redis 服务器成为从服务器及运作原理和治理办法），并只对主服务器进行写入（默认状况下，尝试对一个从服务器进行写入将引发一个谬误，即便它是其余从服务器的主服务器）。P228

增加从服务器 P228

• 在配置文件中加上：slaveof <master-host> <master-port>
• 向正在运行对 Redis 服务器发送：SLAVEOF <master-host> <master-port>

能够通向从服务器发送 SLAVEOF NO ONE 命令让其与主服务器断开。P228

当一个主服务器有大量从服务器时，那么它们以前同步时就会耗尽大部分带宽，导致主服务器提早变高，甚至导致主服务器断开和从服务器的连贯。P229

解决从服务器重同步 (resync) 问题的办法 P229

• 构建树状的从服务器群组：通过构建二级从服务器升高主服务器须要传递给从服务器的数据量
• 对网络连接进行压缩：应用带压缩带 SSH 隧道 (tunnel) 进行连贯能够显著地升高带宽（留神应用 SSH 提供的选项让 SSH 连贯在断线后主动连贯）

故障转移 P230

Redis Sentinel 能够配合 Redis 的复制性能应用，并对下线的主服务器进行故障转移。Redis Sentinel 是运行在非凡模式下的 Redis 服务器，它会监督一系列主服务器以及它们的从服务器，通过向主服务器发送 PUBLISH 命令和 SUBSCRIBE 命令，并向主服务器和从服务器发送 PING 命令，各个 Sentinel 过程能够自主辨认可用的从服务器和其余 Sentinel。当主服务器生效时，监督这个主服务器的所有 Sentinel 就会基于彼此共有的信息选出一个 Sentinel，并从现有的从服务器中抉择一个新的主服务器。而后被选中的 Sentinel 就会让残余的其余从服务器去复制这个新的主服务器（默认设置下，Sentinel 会一个接一个地迁徙从服务器，但这个数量能够通过配置选项进行批改）。P230

Redis Sentinel 还提供了可选的故障转移告诉性能，这个性能能够通过调用用户提供的脚本来执行配置更新等操作。P230

扩大写性能和内存容量 P230

升高内存占用，缩小需写入的数据 P231

• 缩小程序须要读取的数据量
• 无关性能迁徙至其余服务器
• 写入 Redis 前，尝试内存中进行聚合（能够利用于剖析和统计计算）
• 应用锁或者 Lua 脚本代替 WATCH/MULTI/EXEC 事务
• 应用 AOF 长久化会将写入的所有数据存储起来，能够思考配置重写 AOF 或应用 RDB

当应用上述办法无奈持续升高内存并晋升性能之后，就阐明曾经遇到了只应用一台机器带来的瓶颈，那么就须要将数据分片到多台机器下面。咱们介绍应用固定分片数量的办法，使得分片计划可能满足将来几年的预期，假如分片为 256 片。那么后期在数据量十分小的状况下没必要每个 Redis 服务器都应用独立的机器，能够多个 Redis 服务器共用一台机器，或者每个 Redis 服务器应用多个 Redis 数据库。（留神：每台机器上运行多个 Redis 服务器时，确保监听不同的端口，并确保服务器写入的都是不同的快照文件 / AOF 文件。）P231

分片办法能够间接采纳 升高内存占用 中提到的先应用散列函数计算出一个数字散列值，而后应用分片数量计算出以后采纳哪个连贯即可，即不再对 key 进行分片，而是转换为对连贯进行分片。P234

如果执行简单查问时，感觉性能受到了 Redis 单线程设计的限度，并且机器有更多的计算外围、更多的通信网络资源，以及更多用于存储快照文件和 AOF 文件的磁盘 I/O，那么能够思考在单台机器下面运行多个 Redis 服务器。（当然也须要留神：确保一台机器上的多个 Redis 服务器监听不同的端口，并确保服务器写入的都是不同的快照文件 / AOF 文件。）P234

所思

如果网络 I/O 成为瓶颈的话，那么也能够思考 Redis 6.0 的多线程个性。多线程个性次要是改良读写缓冲区的性能，因为这部分工夫占比拟大，而命令执行局部依然应用单线程解决。这样既能进步整体性能，又能够放弃设计简略，也不会引入新的并发问题。

对于一些全局惟一的数据，例如：惟一拜访计数器等，能够额定应用一个连贯专门存储相似的数据。

扩大简单查问 P234

扩大搜寻查问量 P235

实现内容搜寻、定向广告和职位搜寻 中提到的各种搜寻办法都应用了相似 SUNIONSTORE, SINTERSTORE, SDIFFSTORE, ZINTERSTORE, ZUNIONSTORE 等命令，而这些命令都须要对 Redis 进行写入，所以后面介绍的只读从服务器将无奈解决这些搜寻。P235

为了执行上述搜寻，须要开启对从服务器对写入性能。Redis 对配置文件中，slave-read-only 选项管制是否对从服务器进行写入，默认值为 yes。所以只有将 slave-read-only 设置为 no 并重启从服务器，上述搜寻即可失常执行。P235

当机器领有足够多的内存，并且它执行的都是只读操作（或者说这些操作不会批改其余查问所应用的底层数据）的时候，增加从服务器可能帮忙咱们实现横向扩大 (scale out)。

扩大搜寻索引大小 P235

为了对搜寻查问进行连贯分片，咱们必须先对搜寻索引进行连贯分片，确保对于每个被索引的文档来说，同一个文档的所有数据都会被存储到同一个连贯分片外面。P236

分片搜寻理论流程大抵分为以下三个操作：

• 编写可能在单个分片下面执行对查问程序，让它进行搜寻并获取待排序对搜寻后果
• 在所有分片执行下面提到的查问程序
• 对各个分片对查问后果进行合并，而后选出想要的那局部后果

留神：因为无奈确定分页后果中的每条数据别离来自哪个分片，所以为了确保返回的数据在 [start, start + num] 内，程序须要从每个分片获取 [0, start + num] 内的数据，而后在内存中选出最终后果。P236

所思

分片其实也就两种模式：

• 对键进行分片：实用于大量相似键，但每个键对应的数据量不大的状况
• 对数据进行分片：实用于每个键对应对数据量很大的状况

对键进行分片根本和连贯分片绑定了，因为大量键只有在多连贯对状况下分片才有用；而对数据进行分片既能够在单个连贯中变成多个键，也能够转化成连贯分片。

本文首发于公众号：满赋诸机（点击查看原文）开源在 GitHub：reading-notes/redis-in-action