中英文网站后台,怎么做才能发布网站,织梦网站模板还原的文件在哪里,搜索引擎推广前言
随着业务数据的增加#xff08;比如电商业务中#xff0c;随着用户规模和商品数量的增加#xff09;#xff0c;就需要 Redis 能保存更多的数据。你可能会想到使用 Redis 切片集群#xff0c;把数据分散保存到不同的实例上。但是这样做的话#xff0c;如果要保存的…前言
随着业务数据的增加比如电商业务中随着用户规模和商品数量的增加就需要 Redis 能保存更多的数据。你可能会想到使用 Redis 切片集群把数据分散保存到不同的实例上。但是这样做的话如果要保存的数据总量很大但是每个实例保存的数据量较小的话就会导致集群的实例规模增加这会让集群的运维管理变的复杂增加开销。
可能你又想到可以增加 Redis 单实例的内存容量形成大内存实例每个实例就可以保存更多的数据这样一来在保存相同的数据总量时所需要的大内存实例的个数就会减少就可以节省开支。但是基于大内存的大容量实例在实例恢复、主从同步过程中会引起一系列潜在问题例如回复时间增长、主从切换开销大、缓冲区易溢出。
那该怎么办呢 可以使用固态硬盘。他的成本很低每 GB 的成本约是内存的十分之一而且容量大读写速度快我们可以基于 SSD 来实现大容量的 “Redis” 实例。360 公司的 Pika正好实现了这一需求。
Pika 的设计目标
单实例可以保存大容量数据同时避免了实例恢复和主从同步时的潜在问题和 Redis 数据类型保持兼容可以支持 Redis 应用平滑地迁移到 Pika 上。
所以如果你一直在使用 Redis并且想使用 SSD 来扩展单实例容量Pika 是一个不错的选择。 Pika 官网安装教程。 1.大内存 Redis 实例的潜在问题
Redis 使用内存保存数据内容容量增加后就会带来两方面的潜在问题分别是内存快照 RB 生成和恢复效率低以及主从节点全量同步时长增加、缓冲区溢出。
实例内存和内存快照 RDB 的关系是非常直接的实例内存容量大RDB 文件也会相应增加那么RDB 文件生成时的 fork 市场就会增加这会导致 Redis 实例阻塞。而且RDB 文件增大后使用 RDB 进行恢复的时长也会增加会导致 Redis 较长时间无法对外提供服务。
主从节点的同步的第一步就是要做全量同步。全量同步是主节点生成 RDB 文件并传给从节点从节点再加载。想一下如果 RDB 文件很大肯定会导致同步时长增加效率不高而且还可能会导致复制缓冲区溢出。一旦缓冲区溢出了主从节点间就会又开始全量同步影响业务的正常使用。如果我们增加复制缓冲区的容量又会消耗宝贵的内存资源。
此外如果主库发生了故障进行主从切换后其他从库都需要和新主库进行一次全量同步。如果 RDB 文件很大会导致主从切换过程的耗时增加同样会影响业务的可用性。
2.Pika 的整体架构
Pika 键值数据库的整体架构中包括了五部分分别是 网络框架、Pika 线程模块、Nemo 存储模块、RocksDB 和 binlog 机制如下图所示 首先网络框架主要负责底层网络请求的接收和发送。Pika 的网络框架是对操作系统底层的网络函数进行了封装。Pika 在进行网络通信时可以直接调用网络封装好的函数。
其次Pika 线程模块采用了多线程模型来具体处理客户端请求包括一个请求分发线程DispatchThread、一组工作线程WorkerThread以及一个线程池ThreadPool。
请求分发线程专门监听网络端口一旦接收到用户的连接请求后就和客户端建立连接并把连接交给工作线程处理。工作线程负责接收客户端连接上发送的具体命令请求并把命令请求封装成 Task再交给线程池中的线程。由这些线程进行实际的数据存取处理。 在实际应用 Pika 的时候我们可以通过增加工作线程数和线程池的线程数来提升 Pika 的请求处理吞吐率进而满足业务层对数据处理性能的需求。
Nemo 模块很容易理解它实现了 Pika 和 Redis 的数据类型兼容。这样一来当我们把 Redis 服务迁移到 Pika 时不用修改业务应用中的 Redis 的代码而且还可以继续应用运行 Redis 的经验这使得 Pika 的学习成本很低。Nemo 模块对数据类型的具体转换机制下面会进行介绍。
最后RocksDB 提供基于 SSD 保存数据的功能。它使得 Pika 可以不用大容量的内存就能保存更多数据还避免了使用内存快照。而且Pika 使用 binlog 机制记录写命令用于主从节点的命令同步避免了刚刚所说的大内存实例在主从同步过程中的潜在问题。
3.Pika 如何基于 SSD 保存更多数据
为了把数据保存到 SSDPika 使用了持久化数据库 RocksDB。RocksDB 本身的实现机制较为复杂你只要记住 RocksDB 的基本数据读写机制对于学习了解 Pika 来说就已经足够了。下面解释下这个基本读写机制。
Rocks 写数据流程
用一张图片来介绍下 RocksDB 写入数据的基本流程。 当 RocksDB 需要保存数据的时候RocksDB 会使用两小块内存空间Memtable1 和 Memtable2来交替缓存写入数据。Memtable 的大小可设置一个 Memtable 的大小一般为几 MB 或几十 MB。
当有数据需要写入 RocksDB 时RocksDB 会先把数据写入到 Memtable1。等到 Memtable1 写满后RocksDB 再把数据以文件的形式快速写入底层的 SSD。同时RocksDB 会使用 Memtable2 来代替 Memtable1缓存新写入的数据。等到 Memtable1 的数据都写入 SSD 了RocksDB 会在 Memtable2 写满后再用 Memtable1 缓存新写入的数据。
这么一分析我们就知道了RocksDB 会先用 Memtable 缓存数据再将数据快速写入 SSD及时数据量再大所有数据也都能保存到 SSD 中。而且 Memtable 本身容量不大即使 RocksDB 使用了两个 Memtable也不会占用过多的内存这样一来Pika 在保存大容量数据的同时也不用占据太大的内存空间。
RocksDB 读数据流程
当 RocksDB 需要读数据时RocksDB 会现在 Memtable 中查询是否有要读取的数据。因为最新的数据都是先写入到 MemTable 中的。如果 Memtable 中没有要读取的数据RocksDB 会再查询保存在 SSD 上的数据文件。
Redis 面临的 RDB 生成和恢复的效率问题以及主从同步的效率和缓冲区溢出问题在 Pika 中会有类似的问题吗
其实Pika 中是没有这些问题的。
一方面Pika 基于 RocksDB 保存了数据文件直接读取数据文件就能恢复不需要在通过内存快照的方式进行恢复了。而且Pika 从库在进行权利同步时可以直接从主库拷贝数据文件不需要使用内存快照这样一来 Pika 就避免了大内存快照的生成效率低问题。另一方面Pika 使用 binlog 机制实现增量命令同步即节省了内存还避免了缓冲区溢出的问题。binlog 是保存在 SSD 上的文件Pika 收到命令后在数据写入 MemTable 时也会把命令写入 binlog 文件中。和 Redis 类似当全量同步结束后从库会从 binlog 中把尚未同步的命令读取过来这样就可以和主库的数据保持一致。当进行增量同步时从库也是把自己以及复制的便宜量发给主库主库把尚未同步的命令发给从库来保持主从库的数据一致。另外和 Redis 使用缓存区相比使用 binlog 的好处非常明显binlog 是保存在 SSD 上的文件文件大小不像缓冲区会受到内存容量的较多限制。而且当 binlog 文件增大后还可以通过轮替操作生成新的 binlog 文件再把旧的 binlog 文件独立保存。这样一来即使 Pika 实例保存了大量的数据在同步过程中也不会出现缓冲区溢出的问题了。
小结
简单小结下Pika 使用 RocksDB 把大量数据保存到了 SSD同时避免了内存快照的生成和恢复问题。而且Pika 使用 binlog 机制进行主从同步避免了大内存时的影响Pika 的第一个设计目标就实现了。
4.Pika 如何实现 Redis 数据类型兼容
Pika 的底层使用了 RocksDB 来保存数据但是 RocksDB 只提供了 单值的键值对类型而 Redis 键值对中的值还可以是集合类型。Pika 的第二个设计目标如何和 Redis 兼容是如何实现的呢
Pika 中的 Nemo 模块就负责把 Redis 的集合类型转换成单值的键值对。简单来说我们可以把 Redis 的集合类型分成两类
一类是 LIst 和 Set 类型它们的集合中也只有单值。另一类是 Hash 和 Sorted Set 类型它们的集合中的元素是成对的其中 Hash 集合元素是 Field-value 类型而 Sorted Set 集合元素是 member-score 类型。
List 集合
在 Pika 中List 集合的 key 被嵌入到单值键值对的键当中用 key 字段表示而 List 集合中的元素值则被嵌入到单键值对的值当中用 value 字段表示。因为 List 集合中的元素是有序的所以Nemo 模块还在单键值对的 key 后面增加了 sequence 字段表示当前元素在 List 中顺序同时还在 value 的前面增加了 previous sequence 和 next sequence 者两个字段分别表示当前元素的前一个元素和后一个元素。此外在单值键值对的 key 前面Nemo 模块还增加了一个值 “l”表示当前数据是 List 类型以及增加了一个 1 字节的 size 字段表示 List 集合 key 的大小。在单键值对的 value 后面Name 模块 还增加了 version 和 ttl 字段分别表示当前数据的版本号和剩余存活时间用来支持 key 过期功能。
Set 集合
Set 结合中的 key 和元素 member 值都被嵌入到 Pika 单键值对的键当中分别用 key 和 member 表示。同时单键值对的 key 前面有 “s”表示数据类型是 Set 类型同时还有 size 字段用来表示 key 的大小。Pika 单键值对的值只保存了数据的版本信息和剩余存活时间。
Hash 集合
Hash 集合中 key 被嵌入到单键值对的键当中用 key 字段表示。而 Hash 元素的 field 也被嵌入到键值对的键当中紧接着 key 字段用 field 字段表示。Hash 集合元素的 value 字段则是嵌入到单键值对的值当中并且也带有版本号和剩余存活时间。 Sorted Set 集合
对于 Sorted Set 来说该类型是需要能够按照元素的 socre 值排序的而 RocksDB 只支持按照单键值对的键来排序。所以Nemo 在转换数据时就把 Sorted Set 集合 key、元素的 score 和 member 值都嵌入到了 单键值对的键当中。
Pika 单键值对的值只保存了数据的版本信息和剩余存活时间。 5.Pika 的其他优势与不足
和 Redis 相比Pika 最大的特点就是使用 SSD 来保持数据这个特点能带来的最直接好处就是Pika 单实例能保存更多的数据了实现了实例数据扩容。
此外Pika 使用 SSD 来保持数据还有额外两个优势。
首先实例重启快。Pika 的数据在写入数据库时会保存到 SSD 上。当 Pika 实例重启时可以直接从 SSD 上的数据文件中读取数据不需要向 Redis 一样从 RDB 文件全部加载数据或是从 AOF 文件中全部回放操作这极大的提高了 Pika 实例的重启速度可以快速处理业务应用请求。其次主从库执行全量同步的风险低。Pika 通过 binlog 机制实现写命令的增量同步不再受内存缓存区大小的限制所以即使在数据量很大导致主从库同步耗时很长的情况下Pika 也不用担心缓冲区溢出而触发的主从库重新全量同步。
但是Pika 也有自身的一些不足。
虽然它保持了 Redis 操作接口也能实现数据扩容但是当把数据保存到 SSD 上后会降低数据的访问性能。这是因为数据库操作毕竟在内存中直接执行了而是要在底层的 SSD 中进行存取这肯定会影响性能。而且我们还需要把 binlog 机制记录的写命令同步到 SSD 上者会降低 Pika 的写性能。
不过Pika 的多线程模型可以同时使用多个线程进行数据读写这在一定程度上弥补了从 SSD 存取数据造成的性能损失。当然你也可以使用高配的 SSD 来提升访问性能进而减少读写 SSD 对 Pika 的性能影响。
为了更加了解 Pika 的性能情况我从 Pika 官网 上扒出来的一种测试数据表。
操作性能(OPS)写binlog不写binlogSET124K211KGET284K292KHSET122K214KHGET284K290K
从上表的结果中可以看出在不写 binlog 时Pika 的 SET/GET、HSET/HGET 的性能都能达到 200K OPS 以上而一旦增加了 binlog 操作SET/GET、HSET/HGET 的性能大约下降了 41%,只有约 120K OPS。
所以在使用 Pika 时需要在单实例扩容的必要性和可能的性能损失间做个权衡。如果保存大容量数据使我们的首要要求那么 Pika 是一个不错的解决方案。
6.小结
我们学习了基于 SSD 给 Redis 单实例进行扩容的技术方案 Pika。跟 Redis 相比Pika 的好处非常明显既支持 Redis 操作接口又能保持大容量的数据。如果你原来就在应用 Redis现在想进行扩容那么 Pika 是一个很好的选择无论是代码迁移还是运维管理Pika 基本上不需要额外的工作量。
不过Pika 比较是将数据保存到 SSD 上数据访问要读写 SSD 所以读写性能要弱于 Redis。针对这一点有两个小建议
利用 Pika 的多线程模型增加线程数量提升 Pika 的并发请求处理能力为 Pika 配置高配的 SSD提高 SSD 自身的访问性能。
最后Pika 本身提供了很多工具可以帮我我们把 Redis 数据迁移到 Pika或者把 Redis 请求转发给 Pika。比如aof_to_pika 命令并且制定 Redis 的 AOF 文件以及 Pika 的连接信息就可以把 Redis 数据迁移到 Pika 中了如下所示
aof_to_pika -i [Redis AOF文件] -h [Pika IP] -p [Pika 端口] -a [认证信息]可以直接在 Pika 的官网上找到哦啊。并且Pika 本身也还在迭代开发你可以多去 GitHub 看看进一步了解它这样你可以获得 Pika 的最新进制以便能更好地把它应用到你的业务实践中。
