各位老铁们好，相信很多人对教程博客网站源码分享在哪找都不是特别的了解，因此呢，今天就来为大家分享下关于教程博客网站源码分享在哪找以及教程博客网站源码分享在哪找的的问题知识，还望可以帮助大家，解决大家的一些困惑，下面一起来看看吧！
回击就代表输了？！
今年年中，一位前谷歌、前亚马逊的工程师推出了他创作的开源内存数据缓存系统Dragonfly，用C/C++编写，基于BSL许可（BusinessSourceLicense）分发。
根据过往的基准测试结果来看，Dragonfly可能是世界上最快的内存存储系统，它提供了对Memcached和Redis协议的支持，但能够以更高的性能进行查询，运行时内存消耗也更少。与Redis相比，Dragonfly在典型工作负载下实现了25倍的性能提升；单个Dragonfly服务器每秒可以处理数百万个请求；在5GB存储测试中，Dragonfly所需的内存比Redis少30%。
作为一个开源软件，Dragonfly在短短两个月获得了9.2KGitHub星，177个fork分支。虽然这些年，涌现了不少类似的Redis兼容型内存数据存储系统，例如KeyDB、Skytable，但是都没能像这次这么“轰动”。毕竟Redis诞生了十多年，这时从头开始设计一个缓存系统，可以抛弃历史包袱，更好地利用资源。
为回击新冒头的Dragonfly，Redis的联合创始人兼CTOYiftachShoolman和RedisLabs的首席架构师YossiGottlieb、RedisLabs的性能工程师FilipeOliveira联合发布了一篇名为《13年后，Redis是否需要新的架构》的文章。
在文章中，他们特地给出了自认更加公平的Redis7.0vs.Dragonfly基准测试结果：Redis的吞吐量比Dragonfly高18%-40%，以及一些有关Redis架构的观点和思考，以证明“为什么Redis的架构仍然是内存实时数据存储（缓存、数据库，以及介于两者之间的所有内容）的最佳架构”。
虽然他们强调Redis架构仍然是同类最佳，但也没法忽视Dragonfly这些新软件提供的一些新鲜、有趣的想法和技术，Redis表示其中的一些甚至有可能在未来进入Redis（比如已经开始研究的io_uring、更现代的dictionaries、更有策略地使用线程等）。
另外，Redis指出Dragonfly基准测试的比较方法“不能代表Redis在现实世界中的运行方式”。对此，Reddit上有网友反驳称：
它绝对代表了现实世界中普通用户运行Redis的方式。“在单台机器上运行集群，只是为了能够使用超过1个core&34;，那么最好能有更容易的设置。
还有人表示，这篇文章是Redis团队在有礼貌地否认“Dragonfly是最快的缓存系统”，但更多网友表示，Redis发文章进行“回击”，就已经代表他们的营销部门输了：
“Redis投入如此多的工程精力来写这么一篇文章，还对Reids/Dragonfly进行了基准测试，这是对Dragonfly的极大赞美。”“我很高兴Redis发了这篇文章，因此我必须要去了解一下Dragonfly，它看起来很棒。”
Redis博客文章翻译：
作为一项基础性技术，每隔段时间总有人跳出来，想要替Redis换套新架构。几年之前，KeyDB就提出了这类方案，而最近亮相的Dragonfly则声称是速度最快的Redis兼容型内存数据存储系统。没错，这类方案的涌现当然带来了不少值得关注和讨论的有趣技术/思路。在Redis，我们也喜欢迎接挑战，重新审视Redis最初的架构设计原则。
我们当然一直在寻求为Redis提升性能、扩充功能的创新方向，但这里我们想聊聊自己的观点和思考，阐释Redis时至今日为何仍是最出色的实时内存数据存储（包括缓存、数据库以及介于二者之间的一切）方案之一。
接下来，我们将重点介绍Redis对于速度和架构差异的观点，再以此为基础做出比较。在文章的最后，我们还会提供基准测试结果、与Dragonfly项目的详尽性能比较信息，欢迎大家自行对比参考。
速度问题
Dragonfly基准测试其实是将独立单进程Redis实例（只能使用单一核心）与多线程Dragonfly实例（可以使用虚拟机/服务器上的全部可用核心）进行比较。很明显，这样的粗暴比较并不能代表Redis在现实场景下的运行状态。作为技术构建者，我们希望更确切地把握自有技术同其他方案间的差异，所以这里我们做了一点公平性调整：将具有40个分片的Redis7.0集群（可使用其中的大部分实例核心）与Dragonfly团队在基准测试中使用的最大实例类型（AWSc4gn.16xlarge）进行性能比较。
在这轮测试中，我们看到Redis的吞吐量比Dragonfly要高出18%至40%，而这还仅仅只用到全部64个vCore中的40个。
架构差异
背景信息
在我们看来，每一位多线程项目的开发者在立项之前，都会根据以往工作中经历过的痛点来指导架构决策。我们也承认，在多核设备上运行单一Redis进程（这类设备往往提供几十个核心和数百GB内存）确实存在资源无法充分利用的问题。但Redis在设计之初也确实没有考虑到这一点，而且众多Redis服务商已经拿出了相应的解决方案，借此在市场上占得一席之地。
Redis通过运行多个进程（使用Redis集群）实现横向扩展，包括在单一云实例背景下也是如此。在Redis公司，我们进一步拓展这个概念并建立起RedisEnterprise。RedisEnterprise提供管理层，允许用户大规模运行Redis，并默认启用高可用性、即时故障转移、数据持久与备份等功能。
下面，我们打算分享幕后使用的一些原则，向大家介绍我们如何为Redis的生产应用设计良好的工程实践。
架构设计原则
在每个虚拟机上运行多个Redis实例
通过在每个虚拟机上运行多个Redis实例，我们可以：
使用一套完全无共享的架构实现纵向与横向线性扩展。与纯纵向扩展的多线程架构相比，这套方案能始终提供更好的架构灵活性。提高复制速度，因为复制操作是跨多个进程并发完成的。从虚拟机故障中快速恢复。因为新虚拟机的Redis实例将同时填充来自多个外部Redis实例的数据。
将每个Redis进程限制为合理的大小
我们不允许单一Redis进程的大小超过25GB（运行RedisonFlash时上限为50GB）。如此一来，我们就能：
在出于复制、快照保存、AppendOnlyFile（AOF）重写等目的进行Redis分叉时，既享受边写边复制的好处，又无需承担繁重的内存开销。若非如此，我们（或客户）将需要支付昂贵的资源成本。为了轻松管理整个集群，我们希望每个Redis实例都保持在较小体量，借此加快迁移分片、重新分片、扩展和重新均衡等的执行速度。
横向扩展才是最重要的
以横向扩展的方式灵活运行内存数据存储，是Redis获得成功的关键。下面来看具体原因：
更佳弹性——我们在集群中使用的节点越多，整个集群的健壮性就越强。例如，如果您在三节点集群上运行数据集，且其中一个节点发生降级，则代表有三分之一的集群无法运行；但如果是在九节点集群上运行数据集，同样是其中一个节点发生降级，则只有九分之一的集群无法运行。易于扩展——在横向扩展系统当中，向集群添加一个额外节点、并将数据集的一部分迁移到其中要容易得多。与之对应，在纵向扩展系统中，我们只能直接引入一个更大的节点并复制整个数据集……这是个漫长的过程，而且期间随时有可能闹出麻烦。逐步扩展更具成本效益——纵向扩展，尤其是云环境下的纵向扩展，往往对应高昂的成本。在多数情况下，即使只需要向数据集内添加几GB内容，也需要将实例大小翻倍。高吞吐——在Redis，我们看到很多客户会在小型数据集上运行高吞吐量工作负载，即具有极高的网络带宽及/或每秒数据包（PPS）需求。我们以每秒操作数100万+的1GB大小数据集为例，相较于使用单节点c6gn.16xlarge集群（128GB内存、64个CPU加100Gbps传输带宽，每小时使用成本2.7684美元），三个c6gb.xlarge节点（8GB内存、4个CPU外加最高25Gbps传输带宽，每小时0.1786美元）构成的集群能够将运行成本拉低20%，而且健壮性反而更高。既然成本效益出色、弹性更强且吞吐量反超，那横向扩展无疑就是比纵向扩展更好的选择。贴近NUMA架构——纵向扩展还要求使用能容纳更多核心和大容量DRAM的双插槽服务器；相比之下，Redis这样的多处理架构其实更适应NUMA架构，因为其行为特征就接近一种由多个较小节点组成的网络。但必须承认，NUMA跟多线程架构之间也有天然冲突。根据我们在其他多线程项目中的经验，NUMA可能令内存数据存储的性能降低达80%。存储吞吐量限制——AWSEBS等外部磁盘的扩展速度，显然不及内存和CPU。事实上，云服务商会根据所使用设备的类型添加存储吞吐量限制。因此，避免吞吐量限制、满足数据高持久性要求的唯一办法，就是使用横向扩展——即添加更多节点和更多的配套网络附加磁盘。临时磁盘——临时磁盘是一种将Redis运行在SSD上的绝佳方式（其中SSD用于替代DRAM，而非充当持久存储介质），能够在保持Redis极高速度的同时将数据库成本保持在磁盘级水平。但临时磁盘也有其上限，一旦逼近这一上限，我们还需要进一步扩展容量——这时候，更好的办法仍然是添加更多节点、引入更多临时磁盘。所以，横向扩展继续胜出。商品硬件——最后，我们的很多客户会在本地数据中心、私有云甚至是小型边缘数据中心内运行Redis。在这类环境中，绝大多数设备内存不超过64GB、CPU不超过8个，所以唯一可行的扩展方式就只有横向扩展。
总结
我们仍然欣赏由社区提出的种种有趣思路和技术方案。其中一部分有望在未来进入Redis（我们已经开始研究io_uring、更现代的字典、更丰富的线程使用策略等）。但在可预见的未来，我们不会放弃Redis所坚守的无共享、多进程等基本架构原则。这种设计不仅具备最佳性能、可扩展性和弹性，同时也能够支持内存内实时数据平台所需要的各类部署架构。
附录：Redis7.0对Draonfly基准测试细节
结果概述
版本：
我们使用Redis7.0.0，直接通过源码构建Dragonfly使用的则是构建自https://github.com/dragonflydb/dragonfly#building-from-source的6月3日版源码（hash=e806e6ccd8c79e002f721a1a5ecb847bd7a06489）
目标：
验证Dragonfly公布的结果是否可重现，并确定检索结果的完整条件（鉴于memtier_benchmark、操作系统版本等信息有所缺失）确定AWSc6gn.16xlarge实例上可实现的最佳OSSRedis7.0.0集群性能，并与Dragonfly的基准测试结果相比较
客户端配置：
OSSRedis7.0解决方案需要大量接入Redis集群的开放连接，因为每个memtier_benchmark线程都需要连接到所有分片OSSRedis7.0解决方案在使用两个memtier_benchmark进程时成绩最好，而且为了与Dragonfly基准相适应，这两个进程运行在同样的客户端虚拟机上
资源利用与配置优化：
OSSRedis集群在40个主分片的配置下性能表现最佳，对应的就是虚拟机上有24个备用vCPU。虽然设备资源仍未得到全部利用，但我们发现继续增加分片数量已经没有意义，反而会拉低整体性能。我们仍在调查具体原因。另一方面，Dragonfly解决方案彻底耗尽了虚拟机性能，所有64上vCPU均达到了100%利用率。在两种解决方案中，我们调整了客户端配置以实现最佳结果。如下所示，我们成功重现了大部分Dragonfly基准数据，甚至在30通道条件下得出了比项目方更高的测试成绩。本次测试强调与Dragonfly测试环境保持一致，如果调整测试环境，Redis的成绩还有望进一步提升。
最后，我们还发现Redis和Dragonfly都不受网络每秒数据包或传输带宽的限制。我们已经确认在2个虚拟机间（分别作为客户端和服务器，且均使用c6gn.16xlarge实例）使用TCP传递约300B大小的数据包负载时，可以让每秒数据包传输量达到1000万以上、传输带宽超过30Gbps。
分析结果
单GET通道延迟低于1毫秒：
OSSRedis：每秒443万次操作，其中延迟平均值与第50百分位值均达到亚毫秒级别。平均客户端延迟为0.383毫秒。Dragonfly声称每秒400万次操作：我们成功重现至每秒380万次操作，平均客户端延迟为0.390毫秒Redis对Dragonfly——Redis吞吐量比Dragonfly声称的结果高出10%，比我们成功重现的Dragonfly结果高18%。
30条GET通道：
OSSRedis：每秒2290万次操作，客户端平均延迟为2.239毫秒Dragonfly声称每秒可达1500万次操作：我们成功重现了每秒1590万次操作，客户端平均延迟为3.99毫秒Redis对Dragonfly——与Dragonfly的重现结果和声称结果相比，Redis分别胜出43%和52%
单SET通道延迟低于1毫秒：
OSSRedis：每秒474万次操作，延迟平均值与第50百分位值均达到亚毫秒级。客户端平均延迟为0.391毫秒Dragonfly声称每秒400万次操作：我们成功重现了每秒400万次操作，客户端平均延迟为0.500毫秒Redis对Dragonfly——与Dragonfly的重现结果和声称结果相比，Redis均胜出19%
30条SET通道:
OSSRedis：每秒1985万次操作，客户端平均延迟为2.879毫秒Dragonfly声称每秒1000万次操作：我们成功重现了每秒1400万次操作，客户端平均延迟为4.203毫秒Redis对Dragonfly——与Dragonfly的重现结果和声称结果相比，Redis分别胜出42%和99%
用于各变体的memtier_benchmark命令：
单GET通道延迟低于1毫秒
Redis:2X:memtier_benchmark–ratio0:1-t24-c1–test-time180–distinct-client-seed-d256–cluster-mode-s10.3.1.88–port30001–key-maximum1000000–hide-histogramDragonfly:memtier_benchmark–ratio0:1-t55-c30-n200000–distinct-client-seed-d256-s10.3.1.6–key-maximum1000000–hide-histogram
30条GET通道
Redis:2X:memtier_benchmark–ratio0:1-t24-c1–test-time180–distinct-client-seed-d256–cluster-mode-s10.3.1.88–port30001–key-maximum1000000–hide-histogram–pipeline30Dragonfly:memtier_benchmark–ratio0:1-t55-c30-n200000–distinct-client-seed-d256-s10.3.1.6–key-maximum1000000–hide-histogram–pipeline30
单SET通道延迟低于1毫秒
Redis:2X:memtier_benchmark–ratio1:0-t24-c1–test-time180–distinct-client-seed-d256–cluster-mode-s10.3.1.88–port30001–key-maximum1000000–hide-histogramDragonfly:memtier_benchmark–ratio1:0-t55-c30-n200000–distinct-client-seed-d256-s10.3.1.6–key-maximum1000000–hide-histogram
30条SET通道
Redis:2X:memtier_benchmark–ratio1:0-t24-c1–test-time180–distinct-client-seed-d256–cluster-mode-s10.3.1.88–port30001–key-maximum1000000–hide-histogram–pipeline30Dragonfly:memtier_benchmark–ratio1:0-t55-c30-n200000–distinct-client-seed-d256-s10.3.1.6–key-maximum1000000–hide-histogram–pipeline30
测试设施细节
在本次比较测试中，我们在客户端（用于运行memtier_benchmark）和服务器（用于运行Redis和Dragonfly）使用了相同的虚拟机类型，具体规格为：
虚拟机：AWSc6gn.16xlargeaarch64ARMNeoverse-N1每插槽核心数:64每核心线程数:1NUMA节点数:1核心版本:Arm64Kernel5.10安装内存:126GB
参考链接：
https://redis.com/blog/redis-architecture-13-years-later/
https://www.reddit.com/r/programming/comments/wiztpx/redis_hits_back_at_dragonfly/
原文链接：https://www.infoq.cn/article/AlF5NIhHdskayl0MTyQG
好了，关于教程博客网站源码分享在哪找和教程博客网站源码分享在哪找的的问题到这里结束啦，希望可以解决您的问题哈！