chanong 一对一沟通/面试手册/简历优化/求职问题，欢迎加入“知识星球”。 以下是提供的部分信息：
这是一个开源项目，可能对您有用
国内Star是一个10万+的开源项目。 前端包括管理后端+微信小程序，后端支持单体和微服务架构。
功能涵盖RBAC权限、SaaS多租户、数据权限、商城、支付、工作流、大屏报表、微信公众号、CRM等功能：
【国内首批】支持JDK 21+ 3.2.0、JDK 8 + Boot 2.7.18双版本
今年年中，一位前 和 工程师推出了他创建的开源内存数据缓存系统，用 C/C++ 编写，基于 BSL 许可证分发（）。
根据过去的基准测试结果，它可能是世界上最快的内存存储系统。 它提供对Redis协议的支持，但可以执行更高性能的查询，并且在运行时消耗更少的内存。 与Redis相比，在典型工作负载下实现了25倍的性能提升； 单个服务器每秒可以处理数百万个请求； 在5GB存储测试中，它比Redis需要的内存少30%。
作为一款开源软件，它在短短两个月内就获得了 9200 个 star 和 177 个分支。 虽然近年来出现了很多类似的兼容Redis的内存数据存储系统，比如KeyDB，但它们并没有像这个这样“轰动”。 毕竟Redis已经存在十多年了。 从头开始设计缓存系统可以丢弃历史包袱，更好地利用资源。
为了反击新人，Redis联合创始人兼CTO、Redis Labs首席架构师Yossi和Redis Labs性能工程师联合发表了一篇题为《13年后，Redis是否需要新的》的文章。建筑学？”
在文章中，他们特别给出了 Redis 7.0 与他们认为更公平的基准测试结果：Redis 的吞吐量提高了 18% - 40%，以及一些关于 Redis 架构的观点和想法，以证明“Why Redis' ”仍然是内存中实时数据存储（缓存、数据库以及介于两者之间的所有内容）的最佳架构。”
尽管他们强调Redis架构仍然是同类中最好的，但他们不能忽视这些新软件提供的一些新鲜有趣的想法和技术。 Redis表示，其中一些甚至可能在未来进入Redis（比如已经开始研究的，以及更现代、更具战略性的线程使用等）。
此外，Redis 指出该基准测试的比较方法“不能代表 Redis 在现实世界中的运行方式”。 对此，有网友反驳：
它绝对代表了普通用户在现实世界中如何运行 Redis。 “在一台机器上运行集群只是为了能够使用多个核心”是额外的复杂性，只有在别无选择的情况下才会这样做，如果竞争对手可以“正常工作”，那么拥有一个更容易设置。
还有人表示，这篇文章是Redis团队客气地否认“是最快的缓存系统”，但更多网友表示，Redis发表文章“反击”，已经代表了他们营销部门的损失：
“Redis 投入如此多的工程精力来撰写这样的文章并对 Reids/ 进行基准测试，这是一个巨大的赞美。” “我很高兴 Redis 发布了这篇文章，所以我不得不查看一下。突然间，它看起来很棒。”
Redis作为一项基础技术，每隔一段时间总会有人跳出来，想要用新的架构来替代Redis。 KeyDB 几年前就提出了这种类型的解决方案，最新的解决方案号称是最快的兼容 Redis 的内存数据存储系统。 是的，这样的解决方案的出现确实带来了很多值得关注和讨论的有趣技术/想法。 在 Redis，我们也喜欢接受重新审视 Redis 原始架构设计原则的挑战。
当然，我们一直在寻找创新的方向来提高Redis的性能和扩展功能，但在这里我们想谈谈自己的看法和思考，解释为什么Redis仍然是最好的实时内存数据存储（包括缓存、今天的数据库和中介）。 介于两者之间的所有内容）选项之一。
接下来我们重点谈谈Redis对于速度和架构差异的看法，然后在此基础上进行比较。 在文章的最后，我们还将提供基准测试结果以及与项目的详细性能对比信息。 欢迎您自行比较和参考。
基于Boot+Plus+Vue实现的后台管理系统+用户小程序，支持RBAC动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
该基准测试实际上将独立的单进程 Redis 实例（只能使用单个核心）与多线程实例（可以使用虚拟机/服务器上的所有可用核心）进行比较。 显然，这样粗略的对比并不能代表真实场景下Redis的运行状况。 作为技术建设者，我们希望更准确地掌握自己的技术与其他解决方案的差异，因此这里我们做一点公平性的调整：以40个分片的Redis 7.0集群（可以使用大部分实例核心）进行性能对比团队在基准测试中使用的最大实例类型 (AWS c4gn.)。
在这一轮测试中，我们看到 Redis 的吞吐量提高了 18% 到 40%，而这仅使用了 64 个 vCore 中的 40 个。
基于Cloud++Nacos++Vue实现的后台管理系统+用户小程序&支持RBAC动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
1. 背景资料
我们认为，每个多线程项目的开发人员在建立项目之前都会根据之前工作中经历的痛点来指导架构决策。 我们也承认，在多核设备（此类设备通常提供数十个核心和数百GB内存）上运行单个Redis进程确实存在资源利用率不足的问题。 不过Redis在设计之初并没有考虑到这一点，很多Redis服务商也已经拿出了相应的解决方案来在市场上占据一席之地。
Redis 通过运行多个进程（使用 Redis 集群）进行扩展，包括在单个云实例的上下文中。 在 Redis Inc.，我们将这一概念更进一步并构建了 Redis。 Redis提供了一个管理层，允许用户大规模运行Redis，并默认启用高可用性、即时故障转移、数据持久化和备份等功能。
下面，我们计划分享一些幕后使用的原则，向您展示我们如何为 Redis 的生产应用程序设计良好的工程实践。
2. 架构设计原则
1）每个虚拟机上运行多个Redis实例
通过在每个虚拟机上运行多个 Redis 实例，我们可以：
2）将每个Redis进程限制在合理的大小
我们不允许单个 Redis 进程的大小超过 25 GB（在 Flash 上运行 Redis 时限制为 50 GB）。 这样我们就可以：
3）横向扩展最重要
以水平扩展的方式灵活操作内存数据存储是Redis成功的关键。 我们来看一下具体原因：
我们在集群中使用的节点越多，整个集群就会变得越健壮。 例如，如果您在三节点集群上运行数据集，并且其中一个节点降级，则集群的三分之一将关闭； 但如果您在九节点集群上运行数据集，其中一个节点将被降级。 降级后，只有九分之一的集群无法运行。
在横向扩展系统中，向集群添加额外的节点并将部分数据集迁移到其中要容易得多。 相应的，在垂直可扩展的系统中，我们只能直接引入一个更大的节点，复制整个数据集……这是一个漫长的过程，在这个过程中随时都可能出现麻烦。
垂直扩展，尤其是在云环境中，通常对应着高成本。 在大多数情况下，即使您只需要向数据集添加几 GB，也需要将实例大小加倍。
在 Redis，我们看到许多客户在小型数据集上运行高吞吐量工作负载，这些数据集具有极高的网络带宽和/或每秒数据包 (PPS) 要求。 我们以每秒 100 万次以上操作的 1 GB 数据集为例。 与使用单节点 c6gn 相比。 集群（128 GB 内存、64 个 CPU 加上 100 Gbps 传输带宽，每小时使用成本为 $2.7684）。 c6gb 簇。 节点（8 GB 内存、4 个 CPU、高达 25 Gbps 传输带宽、每小时 0.1786 美元）可以降低 20% 的运营成本，并且更加稳健。 由于其成本效益高、弹性更强、吞吐量优越，水平扩展无疑是比垂直扩展更好的选择。
垂直扩展还需要使用双路服务器，可以容纳更多的核心和大容量的DRAM； 相比之下，Redis 等多处理架构实际上更适合 NUMA 架构，因为它们的行为接近于多个较小服务器的行为。 节点网络。 但必须承认，NUMA 和多线程架构之间也存在天然的冲突。 根据我们在其他多线程项目中的经验，NUMA 可以使内存中数据存储的性能降低高达 80%。
AWS EBS等外部磁盘的扩展速度显然不如内存和CPU快。 事实上，云提供商根据所使用的设备类型增加了存储吞吐量限制。 因此，避免吞吐量限制并满足高数据持久性要求的唯一方法是使用水平扩展——即添加更多节点和更多支持网络连接的磁盘。
临时磁盘是在 SSD 上运行 Redis 的绝佳方式（SSD 用于取代 DRAM，而不是充当持久存储介质），将数据库成本控制在磁盘级别，同时保持 Redis 的极高速度。 但临时磁盘也有其上限。 一旦接近这个上限，我们就需要进一步扩大容量。 这时，更好的办法仍然是增加更多的节点，引入更多的临时磁盘。 因此，横向扩展继续获胜。
最后，我们的许多客户在本地数据中心、私有云甚至小型边缘数据中心运行 Redis。 在这种类型的环境中，大多数设备的内存不超过 64 GB，CPU 不超过 8 个，因此唯一可行的扩展方式是水平扩展。
我们仍然感谢社区提出的所有有趣的想法和技术解决方案。 其中一些预计将来会进入 Redis（我们已经开始研究它，更现代的字典，更丰富的线程使用策略等）。 但在可预见的未来，我们不会放弃Redis所坚持的无共享、多进程的基本架构原则。 这种设计不仅提供了最佳的性能、可扩展性和弹性，而且还支持内存实时数据平台所需的各种部署架构。
附录：Redis 7.0 基准测试详细信息
1. 结果总结
1) 版本
我们使用 Redis 7.0.0 并直接从源代码构建。
使用从 #-from- 构建的 6 月 3 日版本的源代码 (hash=)。
2）目标
验证发布的结果是否可重现，并确定检索结果的完整条件（假设缺少操作系统版本和操作系统版本等信息）。
确定在 AWS c6gn 上可实现的最佳 OSS Redis 7.0.0 集群性能。 实例并与基准结果进行比较。
3）客户端配置
OSS Redis 7.0方案需要与Redis集群建立大量的开放连接，因为每个线程都需要连接所有分片。
OSS Redis 7.0 解决方案在使用两个进程时表现最佳，并且为了匹配基准，两个进程都在同一客户端虚拟机上运行。
4）资源利用和配置优化
OSS Redis集群在40个主分片的配置下性能最佳，相当于虚拟机上有24个备用vCPU。 虽然设备资源仍然没有得到充分利用，但我们发现继续增加分片数量没有任何意义，反而会降低整体性能。 我们仍在调查具体原因。
另一方面，该解决方案完全耗尽了虚拟机性能，所有 64 个 vCPU 均达到 100% 利用率。
在这两种解决方案中，我们都调整了客户端配置以获得最佳结果。 如下图所示，我们成功复现了大部分基准数据，甚至在30通道条件下获得了比项目方更高的测试结果。
该测试强调与测试环境的一致性。 如果测试环境调整，Redis的性能有望进一步提升。
最后我们还发现Redis和Redis都不受每秒网络数据包或传输带宽的限制。 我们已经证实，当使用TCP在两个虚拟机（分别作为客户端和服务器，且均使用c6gn.实例）之间传输约300B的数据包负载时，每秒的数据包传输量可以达到1000万个以上。 传输带宽超过。
2 分析结果
1）单个GET通道延迟小于1毫秒
OSS Redis：每秒443万次操作，平均延迟和第50个百分位数均达到亚毫秒级别。 平均客户端延迟为 0.383 毫秒。
声称每秒 400 万次操作：
Redis 对 - Redis 吞吐量比声称的结果高 10%，比我们成功重现的结果高 18%。
2）30个GET通道
OSS Redis：每秒2290万次操作，平均客户端延迟为2.239毫秒
声称每秒能够进行 1500 万次操作：
与再现结果和声称结果相比，Redis 与 Redis 的性能分别高出 43% 和 52%
3）单SET通道延时小于1毫秒
OSS Redis：每秒474万次操作，平均延迟和第50个百分位数均达到亚毫秒级别。平均客户端延迟为0.391毫秒
声称每秒 400 万次操作：
与复制结果和声明结果相比，Redis 与 Redis 的性能优于 19%
4) 30组通道
OSS Redis：每秒1985万次操作，平均客户端延迟为2.879毫秒
声称每秒 1000 万次操作：
与再现结果和声称结果相比，Redis 与 Redis 的性能分别优于 42% 和 99%
每个变体的命令：
1）单个GET通道延迟小于1毫秒
Redis:2X: –ratio 0:1 -t 24 -c 1 –test-time 180 –-seed -d 256 –-mode -s 10.3.1.88 –port 30001 –key- –hide-
: –比率 0:1 -t 55 -c 30 -n ---seed -d 256 -s 10.3.1.6 –key- –隐藏-
2）30个GET通道
Redis:2X: –ratio 0:1 -t 24 -c 1 –test-time 180 –-seed -d 256 –-mode -s 10.3.1.88 –port 30001 –key- –hide- – 30
: –比率 0:1 -t 55 -c 30 -n ---seed -d 256 -s 10.3.1.6 –key- –隐藏- – 30
3）单SET通道延时小于1毫秒
Redis:2X: –ratio 1:0 -t 24 -c 1 –test-time 180 –-seed -d 256 –-mode -s 10.3.1.88 –port 30001 –key- –hide-
: –比率 1:0 -t 55 -c 30 -n ---seed -d 256 -s 10.3.1.6 –key- –隐藏-
4) 30组通道
Redis:2X: –ratio 1:0 -t 24 -c 1 –test-time 180 –-seed -d 256 –-mode -s 10.3.1.88 –port 30001 –key- –hide- – 30
: –比率 1:0 -t 55 -c 30 -n ---seed -d 256 -s 10.3.1.6 –key- –隐藏- – 30
3. 测试设施详情
在本次对比测试中，我们在客户端（用于运行）和服务端（用于运行Redis）使用了相同的虚拟机类型，规格如下：
欢迎加入我的知识星球，全面提升你的技术能力。
如需加入，请“长按”或“扫描”下面的二维码：
的内容包括：实际项目实践、面试招聘、源码分析、学习路线。
文章有帮助的话，在看，转发吧。
谢谢支持哟 (*^__^*）
微信扫一扫打赏
支付宝扫一扫打赏
