共计 5544 个字符，预计需要花费 14 分钟才能阅读完成。
摘要：协定兼容问题、性能问题、数据备份问题、数据容量问题……这些都是数据库在应用过程中必然会遇见的问题。就好比抉择结婚对象，你须要去比照不同的方面，最初选出最好的、最合适的。
本文分享自华为云社区《【云驻共创】Redis 与计算存储拆散四部曲：相识相惜，相辅相成》，原文作者：启明。
近期全国两会正在轰轰烈烈的召开，各人大代表也基于本人的一些实际提出了本人的意见，例如“出台手机设施适老规范”、“老师处分不与升学率挂钩”、“进步留学生招生规范”等等。这些问题必不可少地引来了网上用户的各种探讨声音，你甚至能够设想出网上用户深夜在致力敲键盘的样子……
当然，咱们明天来不是来讲全国两会的。咱们技术人，技术魂，要讲的是这“网上探讨的声音”背地的技术——Redis。现如今咱们网上聊天曾经是粗茶淡饭了，那么你有没有意识到，在咱们聊天的背地，其实是有一个非常复杂的聊天零碎的呢？在这简单的聊天零碎中的音讯推送性能，更是其十分重要的一个模块。一般来说，音讯推送，是采纳 Redis 的历史数据结构来实现的。这个性能的简略使用，就是用户能够通过历史的程序查找，实现查看历史音讯的性能。
与 Redis 相遇
置信到这里，大家对 Redis 的功能强大曾经有肯定认知了。那么咱们来正式介绍一下 Redis：Redis（Remote Dictionary Server )，即近程字典服务，是一个开源的应用 ANSI C 语言编写、反对网络、可基于内存亦可长久化的日志型、Key-Value 数据库，并提供多种语言的 API。Redis 自身有三个长处：快、稳、准，也就是时延低、性能好、数据结构丰盛。如此弱小的 Redis，是“电商秒杀”等业务场景中的“熟客”：将秒杀商品的库存数量存入 Redis，通过 Redis 来提供一个全局库存的实时扣减和查问服务。
然而，没有任何技术是完美无瑕的，Redis 亦如此。Redis 自身有几个毛病：
- Redis 的 bgsave 影响性能；
- Redis 的集群治理的一致性十分弱；
- Redis 的内存限度了它的存储容量
- Redis 的内存利用率只有一半；
- Redis 没有冷热拆散机制。
以上都是 Redis 的一些毛病，是不是看完感觉 Redis 又被“拉下神坛”，不如不必了？不要放弃，针对开源 Redis 的这些毛病，华为云数据库团队，做了“亿点”致力！
与 GaussDB（for Redis）相识
通过千难万险，含辛茹苦，千锤百炼，华为云自研出了一款全新的 Redis 数据库，也即是GaussDB (for Redis)！！！
华为云的自研 Redis 源自于 GaussDB，采纳了最先进的计算存储拆散架构和多模架构——属于业界独创。而 GaussDB，则是华为云数据库的亮点品牌，是华为云引以为傲的数据库架构。
针对华为云的 GaussDB，咱们来做一个简略的介绍吧（架构图如下）：其是基于 DFV 架构来构建的。而 DFV 则是华为外部自研的超级 DataLake（分布式存储池），可用于构建全栈数据服务架构，比方存储局部反对 FusionStorage、云盘 ECS、对象存储 OBS，数据库局部反对的 NoSQL、OLTP，大数据局部则反对 HDFS 的生态、Hadoop、Hbase、Hive 等等。
通过下图能够看到，在下层的数据服务和上层的存储之间，是通过 RDMA 的高性能网络来连贯，从而可能起到一个升高时延的作用。作为最底下的存储层，被分成了不同的存储介质，如 SCM、NVMe SSD、HDD、众核 / 多核等等。不同的存储介质是用来满足不同的服务对于性能的不同的需要的。
这里能够看出，其实 GaussDB NoSQL 就是一套成熟的 DFV 架构，也是集华为整个公司的力量去构建的一个架构最初孵化出的一个产品。其背地的心血、可用性，以及价值，都是难以估计的。
OK，咱们再来看看 NoSQL 的“全家福”（见下图）。能够看到，下图曾经囊括了 NoSQL 的全栈的数据库，包含 Redis、Influx、Cassandra、Mongo 在内，都是基于 GaussDB 雷同的架构去实现的。
拆解来看，这整套架构分为三个档次，从上往下别离是：
- 服务层（Service Layer），次要负责数据库的协定的解析、解决、执行以及回包等等；
- 索引层（Index Layer），次要负责两头的路由及元数据管理等等；
- 继续化存储层（Persistent Layer），也即是 DFV POOL。
当然，咱们明天不会把每个局部都进行解说，而是要对其中的 Redis 进行更深刻的解说，其所领有的 强统一、秒扩容、超可用、低成本这四个特点，让它成为了“家族中最靓的仔”。咱们来一步步深刻理解一下它吧。
与 GaussDB（for Redis）相知
在对 Redis 的四个个性进行深一步解说之前，咱们先对 GaussDB (for Redis)有一个全面的意识吧。从架构设计上（见下图）：
- 设计了中心化的征询治理 –ConfigureSever（cfgsvr）：也就说用它来防止的就是社区 Redis 在集群治理上弱统一的一些问题；
- 设计了 proxy 的接入形式：让一些非 class 的用户通过这个 proxy 接入；
- 设计了 Slot 的数据管理：在最底层的 ShardServer，设计 Slot 的数据管理。是说每一个我的项目 Server 会别离负责不同的 Slot，每个 Slot 又对应不同的数据，最终的数据实际上都是落在最底层的分布式共享存储池（DFV POOL）上。
到这里，置信大家对 GaussDB (for Redis)的架构和性能曾经有了肯定的印象，那么咱们便来具体介绍它的硬实力吧！
硬实力一：强统一
一提到“强统一”，很多业务开发人员会潜意识认为是一个比拟高（fu）级（za）的技术，然而对他 / 她本身的业务逻辑，甚至他 / 她本身代码能力的进步，其实没有任何帮忙。他们会说，“我不须要强统一啊”，或者，“强统一跟我没有关系”。
但咱们听听业界大牛对此的认识：强统一不仅仅是一个技术需要，实际上它也是一个业务需要。咱们如何去了解这句话呢？咱们来举个栗子：三八妇女节刚刚过来，在这个无论大大小小的节日，都要被蹭一波流量的时代，当然少不了电商们的促销流动。电商们在做促销流动的时候，整个平台的流量是十分大的，然而整个零碎可能抗住的压力又十分无限，这个矛盾要怎么解决呢？这里依赖的就是 Redis 的计数器，来构建的一个十分精美的限流机制。
硬件不够，软件来凑。这是当代电商在接受十分大的并发流量的时候的一个根本伎俩。那么 Redis 在这其中是如何发挥作用的呢？咱们来详细分析一下这个限流机制：在 Redis 里是有一个计数器的这么一个性能的。那么咱们在使用过程中，会应用其中一个 key 来做限流。咱们会首先对 key 做一个初始化的赋值，假如赋值 1000。那么，当下层的业务调用 API 的时候，Redis 的限流器就会做一个 decrement 的操作，即进行减 1 的一个操作。每次调用咱们都会减 1，直至 key 的值变为 0，调用会暂停。期待肯定的周期之后，零碎会从新初始化 key，而实现电商在固定周期内限度调用次数的性能。
听着很美妙是不是？然而在这个过程中，却会有一些“意外”产生，其中主从不统一是外围问题。
电商节当天的流量压力之大，不须要咱们赘述。流量压力过大会引发的问题就是，”主”Redis 的 buffer 会产生肯定的沉积，如果再加上”主”Redis 遇上宕机，就会导致”主”从产生切换。鉴于 Redis 的”主”从是异步的，一旦主从产生切换，那么之前在“主”下面做的 decrement 的操作将无奈同步到“从”，最初导致“从”上的流控的数值比实在数值少了很多。然而切换过程，对于下层的调用接口来说，是没有感知的，它将持续尝试调用，即便理论曾经 decrement 至 0，限流器仍然会通过它的申请，最初这些数据都会积淀到最底层、最单薄的 MySQL 数据库，最初导致整个零碎的“雪崩”。
这时候，就是咱们 GaussDB (for Redis)“强统一”性能出场的时候了。针对主从不统一的问题，GaussDB (for Redis)在设计之初就是一个强统一的数据库，摒弃了开源社区的异步赋值机制。它被设计成在存储层（DFV 层）去进行强统一的数据同步，而非在计算层。这样一来，在一开始便防止了任何两头态下的数据的不统一。妈妈再也不必放心咱们宕机导致数据失落啦~
硬实力二：秒扩容
咱们以在疫情期间十分炽热的在线教育为例。假如一个在线教育公司应用 Redis 作为存储介质。Key 对应课程 ID，Field 对应用户 ID。公司在设计之初可能没有思考到疫情会给他们带来爆发式的用户增长，导致哈希收缩，最初冲破 Redis 所在节点的内存限度。那么针对疫情，他们必须要进行扩容。
可是扩容并不是一个简略的事件，甚至能够说是一个高危的操作。因为 Redis 的扩容，是阻塞式的，以 key by key 的形式去进行迁徙，效率十分低下。扩容期间，key 是不可拜访的，并且会继续到扩容完结。
阻塞工夫长是它的第一个问题。第二个问题更加重大。大家都晓得，Redis 不仅有主从，还有 HA（哨兵）。一旦阻塞工夫过长，你的主节点长期没有响应，HA 就会断定你的主节点曾经挂掉，而后把主节点“杀掉”，切换主从关系，让“从”接管申请。留神，这里的切换是产生在扩容迁徙期间的，而一旦产生切换，就会导致扩容迁徙失败，即扩容失败，最初导致哈希的数据一部分散布在源节点，另一部分散布在指标节点。这种景象即便是人工染指也很难修改。
咱们来看看 GaussDB (for Redis)是怎么解决这个问题的。GaussDB (for Redis) 在设计的时候，借助了存算拆散这样一个架构，把 CPU 和 IO 资源进行分池，从而实现按需扩容。 这样的话，在迁徙的时候，就不须要把数据从一个节点拷贝到另一个节点，那么扩容过程就会变得更加轻量且平安。
计算存储拆散的架构，是一个 share everything 的架构。架构底部共享存储，而基于共享存储，底层的 Sever，能够“看”到整个集群的数据选集。当然，这里的看到整个数据选集，只是“看”而非可能“解决”，它只能通过 Slot 的路由器映射去决定它可能解决的那一部分。换句话说，当咱们在做数据扩容和迁徙的时候，只须要将后面所说的路由信息从源节点迁徙到指标节点即可。轻量、平安、平滑，实现秒扩容。
硬实力三：超可用
在数据库畛域，最可怕的事件，莫过于宕机。因为一旦宕机，那么鉴于数据在外围零碎里，会导致整个业务零碎都不可用，从而影响整个业务。因而，数据库必须解决可用性问题。
华为云数据库推出的可用性解决方案，实际上是比高可用更高，咱们称之为“超可用”。它可能容忍 N - 1 个节点挂掉，只有有一个节点活着，那么就能保障整个集群的可用性。
咱们依然以后面的在线教育为例。在线教育的公司会把课程和课程下的用户进行关联，这其中就组成了一个十分大的哈希构造。咱们假如，在十分极其的状况下，此哈希所在分片的 Master 节点和 Slave 节点同时宕机，这必定会影响用户的课程观看。在这种状况下，一般的 Redis 的集群的其余分片尽管看起来还是可用的，然而落到宕机的这个分片的所有申请，都不可用，因为它曾经彻底挂掉了且是 share nothing 的架构，而其余节点也不会看到挂掉节点的数据。那么再来看华为云的 GaussDB（for Redis）是怎么解决的。
鉴于它有共享存储的能力，也即 share everything，它能过把分片上的路由信息，迁徙到剩下的分片，并通过 share everything 能力看到挂掉分片的那局部数据，当初只须要一把“钥匙”，即可解决这部分数据。而这把“钥匙”就是其中一个 Slot 的路由信息：Slot 的路由信息把宕机分片的信息迁徙到“活着”的分片 Sever 上，最初“活着”的 Sever 就领有关上整个集群的“钥匙”。这，就是超可用的设计。
硬实力四：低成本
技术再怎么硬，如果经济老本降本下来，根本是徒劳。假如咱们有一个独角兽公司，它对 Redis 的依赖十分重：历史订单、地图定位、行程轨迹、用户特色、用户标签等等，都存储在 Redis 里。那么这里的数据量肯定是十分大的，甚至能够达到 100TB。那么这么大的一个规模，它外面的老本包含人工运维老本、机房建设、电力供应等等，将会达到千万级 / 年的数量级，这是十分惊人且十分难落地的。因而，降低成本成了必然的抉择。
降低成本的第一步，是要看看老本都花在了什么下面。深入分析过后能够发现，其实这外面有一个“二八准则”。即 80% 的数据是冷数据，80% 的业务对时延性要求没有那么高。基于这样的剖析，就会发现咱们只有利用好“二八准则”，节省成本并不是什么难事。
华为云 GaussDB（for Redis）利用以下几个形式，用无限的估算给用户提供了有限的可能性：
- 冷热拆散，主动替换
- 无备节点，资源省半
- 过程无 fork，内存无半折
- 异步压 / 解，兼顾逻辑核物理算法
与 GaussDB（for Redis）相惜
为什么抉择华为云 GaussDB（for Redis）呢？除了上述咱们要记住的四个个性（强统一、秒扩容、超可用、低成本）之外，咱们还能够从别的中央来看出它的独特性。具体可见下图。
协定兼容问题、性能问题、数据备份问题、数据容量问题……这些都是数据库在应用过程中必然会遇见的问题。就好比抉择结婚对象，你须要去比照不同的方面，最初选出最好的、最合适的。
作为外围数据的存储工具，选对就是商业胜利的一半。当 Redis 遇见计算存储拆散，华为云 GaussDB（for Redis）为此而生。
本文整顿自华为云社区内容共创流动第二期之【线上直播】当 Redis 遇见计算存储拆散。
查看流动详情：https://bbs.huaweicloud.com/forum/thread-111494-1-1.html
点击关注，第一工夫理解华为云陈腐技术~
