#华为云开年采购季#游戏开服、电商大促抢购，在线人数难预估，时常担心写爆Redis，影响活动正常进行。如何解决Redis来不及扩容？推荐使用企业级Redis，支持秒级在线扩容，关键时刻不掉链。限时秒杀新用户包年18元~活动详情→https://activity.huaweicloud.com/dbs_Promotion/index.html 

相信很多用户在实际业务中都会碰到用户会话被中断这样的痛点，这时候其应用程序需要感知到会话变化，并提供复杂的应对措施来解决故障，比如判断数据库连接是否中断，进行事务补偿以及重建数据库会话上下文等。故障背后的原因其实主要是由主备模式的数据库系统在进行主备倒换、小版本升级和规格变更时造成的，但体现在用户层面上则会对业务造成一定的影响。 华为云RDS for MySQL云数据库新特性重磅发布遇到故障后再采取措施明显不利于业务的连续性，也是企业最不想遇到的情况。华为云RDS for MySQL云数据库最新特性——应用无损透明（ALT）重磅发布，专为解决该痛点而打造，能完好地就业务中断问题对症下药，在进行数据库系统切换与故障转移时，可以提供无损的应用连续性，保证企业业务不中断。该功能主要从三个方面来实现：避免连接和事务中断无需用户对事务进行补偿无需恢复和重建会话上下文 应用无损透明（ALT）的功能实现那么，应用无损透明（ALT）为什么能这么厉害？到底是怎么实现业务连续性的呢？我们不妨从它的技术架构上了解一下。应用无损透明（ALT）功能以用户连接为粒度，用户可以连接到数据库代理（Proxy），在进行主备切换、规格变更或者小版本升级时，系统会复制用户的后台会话，在达到安全的事务边界后，确保后端Session操作上下文被完整克隆至目的节点，从而完成主备切换，保证业务无影响。其中，安全的事务边界是指当前会话上的事务提交完成，开启下一个事务之前的状态，例如：开启autocommit的事务块每个语句执行完成时，单独DML、DDL语句，执行完成，都可以达到事务边界。会话克隆能够拷贝和转移会话状态，包括会话系统变量、用户自定义变量和其他上下文，例如`db_name`,`Prepared Statements`等。应用无损透明（ALT）已通过成功验证目前，该功能已经经过完备的测试。使用了该功能，用户可以通过Sysbench，Tpcc-MySQL或MySQL客户端等各种工具链接到读写分离地址，进行主备切换，从而保障用户的业务不会被突然中断。以下分别是使用Sysbench，Tpcc-MySQL和MySQL客户端工具进行主备切换的效果示意，可以看出，不管哪种工具，都可以保证业务的连续性。使用Sysbench进行主备切换的示例使用Tpcc-MySQL进行主备切换的示例非ALT模式下使用Tpcc-MySQL进行主备切换的示例使用MySQL命令行工具主备切换的示例如下图所示，用户自定义变量、会话变量，数据库在主备切换前后均保持一致。为保证主备切换的可靠性，在开通使用应用无损透明（ALT）的同时，可开通Proxy读写分离，通过读写分离地址连接实例，来保证主备切换的可靠性。业务的高安全和高可靠是每个企业的硬性需求。在应用无损透明（ALT）的加持下，华为云RDS for MySQL云数据库将以更优越的容灾能力满足企业多种可用性需求，实时为企业业务保驾护航！【重磅推荐】开年采购享好价！华为云数据库MySQL、GaussDB(for Redis)18元/年限量秒杀，不限新老用户包年3折起。活动期间还有8000元大礼包、满额赠华为笔记本、0门槛抽奖等多重福利！https://activity.huaweicloud.com/dbs_Promotion/index.html

开年采购季倒计时7天！MySQL18元秒杀不容错过，热门规格包年1.5折起，搭配ECS、企业级Redis一起下单，优惠更多。活动期间还有8000元大礼包、满额赠华为笔记本、0门槛抽奖等多重福利！点击查看活动详情→https://activity.huaweicloud.com/dbs_Promotion/index.html

背景：GaussDB(for Redis)是华为云数据库团队推出的企业级Redis，完全兼容开源Redis，既能显著降低成本，又能提供更稳定可靠的KV存储服务。一、一切要从某个深夜的需求说起某天深夜，作为后端小能手的小强强刚准备收工，老板打来电话：“小强强，咱们Redis用的也太杂了，好几十套，啥规格都有！这里面肯定有不少资源浪费！你负责搞个降本增效专项吧，把Redis使用成本降下来，也让运维同学轻松点。”别看我们小伙子年轻，实则经验老道。小强强拍着胸脯接下需求，大致有了思路（如图）： 图1 Redis资源整合+降成本+轻松运维“搞定这件事的核心办法就是‘一Redis多用’！”，小强强立刻想到2个方案：方案1：让业务同学给key加前缀。该方案看似搞定了需求，但隔离性差，大量key前缀占空间，业务改造也很麻烦，因此它并不是优选。方案2：使用Redis的多DB。业务通过select命令访问专属DB，flushdb命令又能一键清数据，隔离效果不错，按理说还是很方便的。二、开源Redis的多DB是鸡肋但是，作为经验十足的后端开发，小强强提前识别到了方案2的严重隐患：开源Redis的“多DB”只能用于单机，不支持集群，搞不定后期扩容。而单机Redis扩容到64G已经是极限，更不用说fork导致的容量利用率只有50%。也就是说，随着后期业务增长，多个业务挤在一套容量只有64G的开源Redis中，意味着当内存不足时，必须得有业务迁出！图2 开源Redis多DB无法扩展，后期只能重新拆分这不就回到了最初的问题**吗？开源Redis的多DB方案明显不符合资深后端的身份，对此，小强强坚决say no！好吧，开源Redis的多DB，看来你是真的帮不上忙！三、当多DB遇上GaussDB(for Redis)前面提到，“多DB”是小强强此刻最需要的功能，但开源Redis多DB却有着后期无法扩容的严重隐患。为了解决问题，小强强找到了真正解决该痛点的产品：GaussDB(for Redis)。在多DB的使用上，GaussDB(for Redis)与开源Redis用法完全一致，实现了同一实例下的数据隔离。GaussDB(for Redis)的多DB核心价值在于：吞吐可水平扩展至百万QPS，容量支持12TB，解决了扩展性问题；相比开源Redis，成本可降20%~70%；单实例支持6w+DB数，搞定大规模业务多租隔离。基于GaussDB(for Redis)多DB功能，业务多租户可以放心共用一套GaussDB(for Redis)，不但轻松实现降本，而且能完美cover住后期业务增长。图3 GaussDB(for Redis)多DB实现业务多租隔离终于搞定一个靠谱方案！小强强可以放心地交差了。最后，再一次为好用的产品打call：GaussDB(for Redis)支持真正可扩展的多DB，轻松降本，简直yyds！四、附录本文作者：华为云数据库GaussDB(for Redis)团队杭州/西安/深圳简历投递：yuwenlong4@huawei.com官方博客：https://bbs.huaweicloud.com/blogs/248875华为云开年采购季盛大开幕！点击了解详情：https://activity.huaweicloud.com/dbs_Promotion/index.html

文章来源：CSDN正值企业数字化转型全面提速之际，业务需求急速增加，伴随而来的是数据量和并发访问量呈指数级增长，传统关系型数据库在处理海量大数据时显得力不从心。由于局部性原理的限制，在使用传统数据库来处理大数据流，在初始建表时表中大量的数据项被置空，这对于传统数据库来说是灾难性的。在关系型数据库中，建表时须定义表结构，字段动态增减对于性能的影响巨大，同时带有大量空值稀疏矩阵的存储会导致存储成本的急剧增加，这给了NoSQL 型数据库以极**展空间，而Redis作为 NoSQL 的翘楚，备受业界追捧。开源版本的Redis 5.0 提供了包括 String、List、Set、ZSet、Hash、Bit Array、HyperLogLog、Geo、Streams 九种数据类型，以及建立在这些数据类型上的相关操作，给开发人员更多的选择空间来表达数据和数据间的相互关系。但开源版Redis从本质上讲并不是一款数据库，主要有以下几方面的弱点：1.使用场景有限，只能达到弱一致性的水平，一般只能在缓存层使用；2.使用成本高，由于开源版Redis使用内存作为存储主体，内存居高不下的价格使搭建Redis集群的成本极高；3.运行不稳定，经常使用开源版Redis的读者肯定了解，在进行如大key替换时、扩容、缩容等操作时，经常遇到阻塞、抖动等问题。于是本文我们选择了在业界有着良好口碑GaussDB(for Redis)进行了对比评测，以向各位读者推荐一款真正质优价廉的Redis。下面我们具体展开聊聊：GaussDB(for Redis)：稳定可靠在使用缓存方案时，用户最害怕见到的场景就是Redis由于各种原因性能下降，使业务流量的压力直接向核心数据库转移，最终造成整个系统的雪崩。可以说运行稳定性是用户在对于缓存数据库选型时需要考虑的首要问题，因此我们选择了切换、重启与备份三个在日常工作中经常会遇到的场景进行开源版本Redis与GaussDB(for Redis)进行整体使用感受层面的对比评测。1.灾备切换场景：首先通过在控制台强行将主节点关机，模拟开源Redis主节点故障与GaussDB(for Redis)单个节点故障，其中特别说明：由于GaussDB(for Redis)采用多个节点同时工作的负载均衡方案，因此没有开源Redis中的主节点概念，因此灾备切换时任选某一节点宕机，即可模拟灾备切换的场景。具体如下：可以看到GaussDB(for Redis)在切换过程中服务会瞬间迁移至备节点，而且切换过程中性能下降也不明显，整体只需要1s就可以恢复正常。而对比开源版Redis在切换时则会出现服务完全中断的情况，平均需要5s才能恢复。可以说GaussDB(for Redis)的表现让我完全不会担心在主节点发生异常时，使整个交易链路全部崩溃的情况，但是开源版Redis，在遇到切换时就会比较提心吊胆了。2. 节点故障恢复场景：节点异常重启是Redis使用中所经常遇到的问题，我们知道开源版Redis服务重启时需要加载元数据也就是RDB，Key值越多RDB也就越大，重启速度就越慢，16G规格的开源版Redis服务重启速度约需要10秒左右，而作为对比GaussDB(for Redis)重启时没有重新加载元数据的步骤，因此重启速度很快，几乎可以在1秒内完成重启操作，而且重启速度不受数据量影响。3. 备份场景：对于开源版Redis来说系统备份会触发fork操作，fork操作是标准的POSIX操作系统接口，调用时会产生内存分配、拷贝等等一系列动作，这会使时延大幅度增长，造成开源版Redis在备份等日常运维操作时出现明显的抖动现象，甚至极端情况下还会使内存使用率大幅飙升，触发操作系统OOM保护使Redis进程异常中止，因此开源版的Redis只能在业务低谷期进行备份操作，对于全天候24小时都存在交易高峰的系统就不适用。不过GaussDB(for Redis)从系统底层解决了备份时的fork问题，备份时根本不需要fork操作，数据随时可备，高峰期也不干扰。从总体的使用感受来看，GaussDB(for Redis)在稳定性方面几乎碾压开源版本Redis的，堪称是用户系统中的定海神针，下面我们再就具体扩容、性能、价格等方面的情况进行详细评测。 GaussDB (for Redis)：秒级扩容从事开源Redis运维工作的读者，一般都会有掉进过扩容的坑，由于开源 Redis使用内存作为数据的存储，各节点间使用 Raft 协议进行数据同步，这使开源 Redis在扩容时操作较复杂，尤其在对服务器进行内存扩容时，一般都需要对于所在ECS实例进行重启，这一系列的操作必然伴随着主节点的切换与重启，使服务暂时中断。1.扩容过程中的服务性能对比：开源Redis是弱一致的缓存数据库，数据即使没有落盘持久化也可能向调用方法返回写入成功，因此一旦发生切换，那么难免出现脏读现象，因此扩容可以说是开源版Redis日常运维过程中最令使用者头疼的问题。针对扩容场景我们同样对于GaussDB(for Redis)与开源 Redis也进行了相应评测：2.扩容操作便利性对比：从操作层面上讲GaussDB(for Redis)在扩容时比开源 Redis 简单得多，只需要在华为云的操作台上进行简单操作即可，在笔者近百次不断扩容操作当中，GaussDB(for Redis)从未出现过服务中断及数据丢失的情况，扩容操作秒级完成，外部零感知，对比开源版本，操作复杂需要不断地重启、切换不说，在扩容过程中平均会有25秒左右的服务中断。不仅扩容时不再需要提心吊胆，GaussDB(for Redis)的配套监控系统比开源 Redis 完善，不仅可对请求时延等关键性能指标可视化监控，还可实现故障节点自动摘除、平滑移动、自动告警、自动恢复，给使用者提供了绝佳的运维体验。 GaussDB(for Redis)：强悍性能与内存相比，磁盘无论在稳定性还是可维护性上都有非常强大的优势，从本质上讲GaussDB(for Redis)实际上都得益于其磁盘作为数据的存储设备，内存的优势是速度快，笔者在评测之前认为GaussDB(for Redis)可能会比开源版本有差距，但实际的测试结果却证明在相同的规格下GaussDB(for Redis)与开源版本的差距微乎其微。1.一般场景性能对比：在我们测试的16G规格下，GaussDB(for Redis)甚至还略高于开源Redis，具体如下：2.大key替换场景性能对比：而且GaussDB(for Redis)也完全解决了开源 Redis在进行 key 值替换时的卡顿问题。在模拟大key替换的场景下，具体如下：在对大Key进行替换、读写操作时，GaussDB(for Redis)性能几乎没有受到任何影响，这与开源版本动辄下降20%的情况相比，实在令人惊喜。3.GaussDB (for Redis)的性能密码剖析这背后的原因，在于GaussDB(for Redis)通过存储层 Shared Everything 解决了开源 Redis 在批量 key 替换时产生的卡顿问题，GaussDB(for Redis)的存算分离架构不但屏蔽了各个不同独立数据库之间的底层细节，让存储的归存储，计算的归计算，将各种能力封装到模块中，用户任意挑选适合组件，根据自身的业务需求、以极小的成本来定制化数据库服务。在这个过程中还保证了完整的用户体验一致性。GaussDB(for Redis)利用 hash 策略对数据进行均衡，不存在 Full GC 造成的 STW 问题，这些技术方案的运用让GaussDB(for Redis)完美解决了开源版本经常出现的卡顿问题，真正做到了“丝丝顺滑，完全不卡”。GaussDB(for Redis)通过冷热分离技术动态发现热点数据，并将热点数据有序调入内存，在客户看来，几乎感受不到GaussDB(for Redis)与开源Redis时的性能差距。GaussDB(for Redis)有开源Redis不具备的优势，就是不受内存容量限制，支持PB级的缓存集群，规模越大GaussDB(for Redis)的性能还越好，从华为云的官方资料上看，GaussDB(for Redis)性能可以轻松达到百万级的QPS。得益于GaussDB(for Redis)负载均衡的架构方案，只要集群中有一个节点还是可用的，整个集群就能正常对外服务，正常情况下每个节点都可支持写入，这种架构在正常情况下可以保证对外的高性能，在异常时又支持N-1级别的容错特性，在性能及容灾方面的对比GaussDB(for Redis)又是领先于开源版Redis。 GaussDB(for Redis)：极致性价比为了对比这两者的性价比，我们采购了某厂商的 2C/16G、4C/64G两种规格的ECS云服务器各3台，搭建开源Redis版本的集群，并与华为云上用同规格的 GaussDB(for Redis)进行价格对比，由于具体性能指标的对比前文已经列出，这里不再加赘述。我们可以看到单位数据量的GaussDB(for Redis)在性价比层面可以比开源Redis平均提高近1倍。从评测结果来看，GaussDB(for Redis)是一款超越开源版本的优秀产品，在各方面的指标几乎全面超越了开源版本，总结上述评测结果如下：由于GaussDB(for Redis)基于华为高性能分布式共享存储池，完美避开开源Redis 的主从堆积、主从不一致、fork 抖动、内存利用率只有 50%、大 key 阻塞、gossip 集群管理等诸多问题，购买的容量全部可用，并且单位数据的使用成本只有开源版本的一半。开发者们，现在不试试GaussDB(for Redis)更待何时？ 华为云开年采购季 盛大开幕！玩法多多，特惠多多服务器低至0.3折，数据库只要￥18/年；集云福卡领华为平板电脑、千元购物卡；抽奖专区100%中奖，最高得华为典藏版手表；更有13大场景专场，满足更多上云需求！#开年就选华为云_天天都是好日子

近日，网上一些电商用户出现了库存业务查询超时的现象，深究根源，是其使用的Redis云服务底层SSD卡硬件故障，影响了Redis的稳定性，最终导致业务超时。此时笔者脑中闪过一连串问号：那么，缓存Redis究竟为啥绕不过磁盘这道坎呢？从技术角度讲，使用缓存Redis还要配磁盘，一方面是因为开源Redis依赖持久化机制，保证宕机后能取回一部分数据，另一方面这也是主从同步必不可少的。开源Redis提供了两种持久化方案——RDB和AOF，其中：RDB是通过对内存打快照的方式，将数据备份到磁盘。开源Redis主从之间全量同步就依赖于RDB文件。AOF是通过日志追加的方式记录数据变化。开源Redis宕机重启可用AOF文件加载“较为完整”的数据。想到这里，笔者恍然大悟：电商用户的现网问题，原来就在于RDB和AOF机制都要进行磁盘IO，而磁盘故障直接影响了Redis的持久化，进而阻塞了Redis的正常服务！除此之外，缓存Redis的持久化还有各种缺陷：AOF写入频率通常只能配置为秒级，在Redis动辄十万QPS的情况下，宕机时仍会有大量数据无法找回；数据量越大，重启加载AOF越缓慢；RDB的生成和AOF重写都会引发fork问题，造成性能抖动。由此可见，缓存Redis的持久化既不稳定、也不可靠，甚至还会因为磁盘性能、fork问题导致上层业务不稳定。然而出于数据“相对”安全、可靠的需求，缓存Redis还真就跨不过磁盘这道坎。 自建Redis的朋友们难免遇到这种窘境：最开始配了一个普通磁盘，后来遇到各种持久化阻塞服务的问题，不得不对磁盘进行升级。回顾前文的Redis实例故障，我们不难发现：缓存Redis的持久化与磁盘问题似乎永远无法令人放心。 那么，是否有一劳永逸的方案，可以和Redis持久化带来的问题说拜拜呢？ GaussDB(for Redis)作为华为云主推的企业级Redis，有着稳定可靠的天然优势，其基于存算分离、多副本强一致的架构，摒弃了RDB/AOF机制，彻底解决了开源Redis持久化性能不稳定、数据不一致、磁盘不可靠等问题，帮助企业用户真正实现降本增效。 那GaussDB(for Redis)都有哪些“黑科技”呢？采用SPDK技术，通过用户态、异步、无锁、轮询的方式驱动磁盘，相比开源Redis内核态驱动，速度大幅提高。高性能分布式共享存储池采用RDMA和DPDK技术，极大提高了系统吞吐量，加速数据处理，降低通信延迟。采用SCM技术，将接近内存的性能和速度，与类似SSD的容量和成本结合起来，打造强悍底座。正是如此，GaussDB(for Redis)在保证数据命令级落盘的同时，能够轻松支持百万级QPS的高并发访问，以及亚毫秒级时延。其底层使用高性能分布式共享存储池，不会因磁盘故障而阻塞服务；同时，硬件成本又远低于缓存Redis，且数据量越大性价比越高。 既然Redis离不开持久化、离不开磁盘，那何不选择一款兼具性能与持久化优势的Redis数据库呢？就如上文提到的电商场景，GaussDB(for Redis)凭借独有的强一致、稳定性、ACID事务，不但能轻松搞定“库存”业务，其强大的持久化能力更能够为企业核心数据存储保驾护航。 本文作者：华为云数据库GaussDB(for Redis)团队更多产品信息，欢迎前往华为云GaussDB(for Redis)官网杭州/西安/深圳简历投递：yuwenlong4@huawei.com

华为云会员年末福利来袭~云数据库MySQL、GaussDB(for Redis)等产品新用户低至12元，包年1折起！领取万元红包，消费满额送华为保时捷设计手机！更多活动信息请前往云数据库专场：https://activity.huaweicloud.com/dbs_Promotion/index.html

本文转自墨天轮，作者：杨明翰，原文链接：https://www.modb.pro/db/171623GaussDB(for Redis) 是华为云推出的企业级Redis，采用计算存储分离架构，兼容Redis生态的云原生NoSQL数据库，基于共享存储池的多副本强一致机制，支持持久化存储，保证数据的安全可靠。具有高兼容、高性价比、高可靠、弹性伸缩、高可用、无损扩容等特点。GaussDB(for Redis)满足高读写性能场景及容量需弹性扩展的业务需求，广泛使用于电商、游戏以及视频直播等行业。即可作为前端缓存支撑大并发的访问，也可作为底层数据库负责核心数据可靠存储。接下来我们使用采用Redis Labs推出的多线程压测工具memtier_benchmark对比测试下GaussDB(for Redis) 和原生Redis的特性差异。目录导航1、创建GaussDB(for Redis)实例2、安装memtier_benchmark3、数据批量装载向GaussDB(for Redis) 中装载数据向原生Redis中装载数据4、实例紧急扩容GaussDB(for Redis)扩容到16G原生Redis扩容到16G5、数据淘汰问题插入数据到GaussDB(for Redis)插入数据到原生Redis6、测试总结1、创建GaussDB(for Redis)实例在华为云通过控制台购买GaussDB(for Redis)实例，测试实例的配置为8G容量，如下所示。如截图所示，GaussDB(for Redis)提供了统一的负载均衡地址和端口，方便应用程序访问高可用的Redis服务。持久化数据存储空间直观展示了数据量及容量上限。另外，依托于GaussDB(for Redis)存算分离的架构，实例的容量和性能可以按需分别扩展：如需更多容量，只需点击“磁盘扩容”；如需更高的吞吐性能，则通过“规格变更”或“添加节点”完成。2、安装memtier_benchmark使用与GaussDB(for Redis)测试实例相同子网的ECS云服务器，部署memtier_benchmark测试环境# yum install autoconf automake make gcc-c++ # yum install pcre-devel zlib-devel libmemcached-devel openssl-devel # git clone https://github.com/RedisLabs/memtier_benchmark.git # cd memtier_benchmark # autoreconf -ivf # ./configure # make && make install 如libevent版本较低，需要在安装memtier_benchmark前 按以下步骤安装libevent # wget https://github.com/downloads/libevent/libevent/libevent-2.0.21-stable.tar.gz # tar xfz libevent-2.0.21-stable.tar.gz # pushd libevent-2.0.21-stable # ./configure # make # sudo make install # popd # export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:${PKG_CONFIG_PATH} 确认安装成功 # memtier_benchmark --help3、数据批量装载向GaussDB(for Redis) 中装载数据使用memtier_benchmark向GaussDB(for Redis) 中装载数据命令如下，单个value长度1000字节，12个线程，每个线程16个客户端，每个客户端发出请求数100000个，全部是写入操作。memtier_benchmark -s 192.XXX.XXX.XXX -a XXXXXXX -p 8635 -c 16 -t 12 -n 100000 --random-data --randomize --distinct-client-seed -d 1000 --key-maximum=65000000 --key-minimum=1 --key-prefix= --ratio=1:0 --out-file=./result_small_6G_set.log可以看到执行了1920万次操作，平均每秒4.4w的ops，总耗时438秒。使用redis-cli登录实例，查看dbsize（注意：由于采用MVCC机制，查询结果为key数量的预估值，非实时的准确值。）向原生Redis中装载数据为了对比方便，我们在另一台4核8G的ECS上部署一个单节点的开源Redis，版本与GaussDB(for Redis)一致使用5.0还是使用memtier_benchmark相同的配置向原始redis中插入数据memtier_benchmark -s 192.XXX.XXX.XXX -a XXXXXXX -p 6379 -c 16 -t 12 -n 100000 --random-data --randomize --distinct-client-seed -d 1000 --key-maximum=65000000 --key-minimum=1 --key-prefix= --ratio=1:0 --out-file=./result_small_6G_set_2.log执行一段时间后出现大量报错从Redis日志中查看，是在做RDB快照的时候出现了问题。从系统日志中分析当时发生了OOM故障。这其实和原生Redis的RDB快照处理方式有关，Redis是fork了一个进程使用copy-on-write的方式持久化内存数据，这必然会导致更多内存的申请和使用。并且除了RDB快照，原生redis在执行aof重写，新加从库的操作时也会申请使用更多的内存。为了避免OOM的情况出现，操作系统往往要预留出一倍的空闲内存，限制了内存资源的使用率造成极大的浪费。反观GaussDB(for Redis) 由于摒弃了fork机制，使得架构更健壮。从上面的测试也可以看到，导入同样数量的数据时，GaussDB(for Redis) 的可用性和响应的性能没有受到任何的影响。4、实例紧急扩容为了测试能进行下去，我们将GaussDB(for Redis) 和原生Redis分别扩容到16G。GaussDB(for Redis)扩容到16G对GaussDB(for Redis) 来说由于采用了存算分离的架构，分布式存储池海量在线，按额度分配给用户使用。扩容过程没有数据拷贝，也不会影响业务使用。接下来我们测试使用memtier_benchmark在持续的RW操作场景下GaussDB(for Redis)的扩容过程，看看是否会影响业务的读写；memtier_benchmark -s 192.XXX.XXX.XXX -a XXXXXXXX -p 8635 -c 16 -t 12 -n 10000 --random-data --randomize --distinct-client-seed -d 1000 --key-maximum=65000000 --key-minimum=1 --key-prefix= --ratio=1:0 --out-file=./result_small_6G_set_get.log在执行命令的同时进行扩容操作，查看测试结果和监控发现，扩容期间未见报错，GaussDB(for Redis) 响应时延没有明显变化。原生Redis扩容到16G原生Redis实例受服务器内存限制，要扩容到16G只能先升级ECS配置。需要重启服务器，存在短时间业务不可使用的问题。升级后再次使用memtier_benchmark插入数据依旧报错，检查发现还是出现了OOM没办法，只能再次升级云服务器ECS配置到32G，升级期间Redis服务再次不可用。这次升级后终于使用memtier_benchmark成功的插入了数据。5、数据淘汰问题下面我们来看高压力下导致数据写满的场景，直观对比双方的表现。插入数据到GaussDB(for Redis)memtier_benchmark参数设置如下，全部为写入操作，set的单个value长度50k字节，12个线程，每个线程16个客户端，每个客户端发出请求数10000次请求。折算下来 总的插入的key约为192万，数据量约96G，远大于实例的规格了。memtier_benchmark -s 192.XXX.XXX.XXX -a XXXXXXX -p 8635 -c 16 -t 12 -n 10000 --random-data --randomize --distinct-client-seed -d 50000 --key-maximum=65000000 --key-minimum=1 --key-prefix= --ratio=1:0 --out-file=./result_small_6G_set.log 运行了一段时间后，从监控上看到GaussDB(for Redis)磁盘空间100%，并且实例进入只读模式拒绝新数据的写入。检查发现共导入数据194954条。对于GaussDB(for Redis)来说，当容量接近写满的时候，用户会收到告警通知，此时只需在控制台点击“磁盘扩容”，即可秒级完成扩容，对业务没有影响。插入数据到原生Redis原生Redis通过配置限制了内存大小为8G，同样执行以下命令导入数据memtier_benchmark -s 192.XXX.XXX.XXX -a XXXXXXX -p 8635 -c 16 -t 12 -n 10000 --random-data --randomize --distinct-client-seed -d 50000 --key-maximum=65000000 --key-minimum=1 --key-prefix= --ratio=1:0 --out-file=./result_small_6G_set.log 运行一段时间后报错。登录redis查看内存已写满也可以通过配置maxmemory-policy设置数据淘汰策略保障数据写入，如图我们将淘汰策略设置成allkeys-lru，即淘汰最近最少使用的key 满足插入数据的内存需求；修改配置后 插入正常综上，GaussDB(for Redis)更加看重数据安全，将“保障用户数据不丢”作为最高优先级。当数据写满后自动进入只读模式，确保实例中数据的安全。通过控制台可以做到快速的扩容，最大可能降低对业务的影响。 原生Redis提供了数据淘汰参数，用户可自主选择策略当数据写满后淘汰符合条件的数据，设计思想更偏向于缓存的用途“数据可随意丢弃”。如使用在重要的业务场景，不希望数据丢失，建议选择GaussDB(for Redis)。6、测试总结本次我们使用memtier_benchmark分别对GaussDB(for Redis) 和原生Redis进行set操作的测试，8G规格的GaussDB(for Redis) 很顺利的完成了数据加载的操作，原生Redis出现OOM异常导致数据加载失败。原生Redis通过fork进程copy-on-write的方式拷贝数据，在RDB快照、aof重写以及新增从库等操作时容易出现OOM异常。反观GaussDB(for Redis) 由于摒弃了fork机制，使得架构更健壮，服务的可用性更强。在后续的扩容操作中GaussDB(for Redis)能够快速完成且对业务RW操作无影响，而原生Redis扩容需停服，期间业务无法正常使用。GaussDB(for Redis)快速扩容的特性非常适合生产环境中需要紧急扩容的场景，如游戏开服、电商抢购的火爆程度远超预期时。从测试的情况看，扩容几乎达到了秒级完成，且扩容过程中对业务的读写完全没有影响。另外更重要的原生Redis无论采用RDB还是aof方式进行数据持久化，都有数据丢失的风险，而GaussDB(for Redis)支持全量数据落盘，GaussDB基础组件服务提供底层数据三副本冗余保存，能够保证数据零丢失。如果使用场景既要满足KV查询的高性能，又希望数据得到重视能够不丢，建议从原生Redis迁移到GaussDB(for Redis) 。

有人说，开源Redis的最终一致性已经能满足大部分应用场景，也有人说，多副本的强一致代价太大，没有必要实现。要笔者说，其实弱一致性已经不满足很多应用场景的诉求。怎么，不信？请听笔者娓娓道来。1.不一致带来的困扰1.1 秒杀变秒崩分享一个电商秒杀活动中限流器的例子，在电商的秒杀活动中，为了扛住前端对数据库的超大流量冲击，一般使用两种方案来保护系统，一个是缓存，另一个则是限流。缓存这个容易实现，只需要在数据库前加一层缓存服务器，而对于限流来说，最简单的可以使用Redis的计数器来实现限流功能。具体来说，假设我们需要对某个接口限定流量为5000QPS，即每秒钟访问的次数不能超过5000。那么我们可以这么做：在一开始的时候设置一个计数器counter为5000，并且过期时间为1s，即1s后计数器失效。每当一个请求过来的时候，counter的值减1，判断当前counter的值是否等于0，如果等于，则说明请求次数过多，直接拒绝请求。如果counter计数器不存在，则重置计数器为5000，开始新一秒的接口限流，注意并发情况下计数器需要加锁。正常情况下，这种方案不会出现问题，但是针对这种秒杀活动，不怕一万，就怕万一，万一Redis突然宕机怎么办，那岂不是限流器形同虚设，所有流量全部涌向后端的数据库，瞬间系统崩溃。此时聪明的你肯定会想到，给Redis搞一个备用服务器不就解决了，主服务器如果宕机，备用服务器顶上。没错，这种方案是对的，但是只正确了一半。为什么呢，如下图所示。当给Redis配置从服务器之后，如果主服务器出现宕机，可以立刻切换到从服务器，但是由于开源Redis主从服务器之间的数据是异步复制的，如果网络不畅，经常发生主从数据不一致，如果此时主服务器发生宕机，切换到从服务器之后，因为限流器的判断出错，流量压力很容易超出阈值，一下子涌向数据库服务器，同样会造成系统崩溃。仔细探究这个问题产生，根因是在于开源Redis的一致性机制为弱一致性，在某些时间内，主从副本数据不一致。而要彻底解决这个问题，只有真正的强一致才能解决。1.2 难以维护的MySQL组件其实不止Redis，就连大名鼎鼎的MySQL也逃不过弱一致的坑。MySQL的部署中，为了保证高可用性，主从热备份是MySQL常用的部署方式。但是如果发生故障时，仅仅靠MySQL自身的同步机制，是无法保证主库和从库之前的数据一致的，于是出现了重要的辅助组件MHA(Master High Availability)，它的部署方式如下：MHA由管理服务和Node服务组成，Node服务部署在每个MySQL节点上，MHA组件负责让MySQL的从库尽可能的追平主库，提供主从一致的状态。发生故障进行主从切换时，Manager首先为从库补充落后的数据，然后再将用户访问切换到从库，这个过程可能长达数十秒。MHA的部署和维护都相当复杂，如未能顺利执行故障切换或发生数据丢失，运维面临的场面都将很棘手。其实运维同学何尝不希望手中的系统稳定运行呢？要是数据库自身能提供强一致保障，何苦再依赖复杂的辅助组件！2.什么是强一致上一节中笔者介绍了弱一致带来各种问题，接下来这一节具体介绍下什么是强一致。在“分布式系统”和“数据库”这两个领域中，一致性都是重要概念，但它表达的内容却并不相同。对于分布式系统而言，一致性是在探讨当系统内的一份逻辑数据存在多个物理的数据副本时，对其执行读写操作会产生什么样的结果，这也符合 CAP 理论对一致性的表述。而在数据库领域，“一致性”与事务密切相关，又进一步细化到 ACID 四个方面。因此，当我们谈论分布式数据库的一致性时，实质上是在谈论事务一致性和数据一致性两个方面。2.1 事务一致性事务的一致性主要是指的事务的ACID，分别是原子性、一致性、隔离性和持久性，如下图所示：原子性：事务中的所有变更要么全部发生，要么一个也不发生，通过日志技术实现；一致性：事务要保持数据的完整性，它是应用程序的属性，依赖原子性和隔离属性来实现；隔离性：多事务并行执行所得到的结果，与串行执行（一个接一个）完全相同，通过并发控制技术来实现；持久性：一旦事务提交，它对数据的改变将被永久保留，不应受到任何系统故障的影响，通过日志技术实现。2.2 数据一致性在分布式系统中，为了避免网络不可靠带来的问题，通常会存储多个数据副本，逻辑上的一份数据存储在多个物理副本上，自然带来了数据一致性问题。（1）状态视角从状态的视角来看，任何变更操作后，数据只有两种状态，所有副本一致或者不一致。在某些条件下，不一致的状态是暂时，还会转换到一致的状态，而那些永远不一致的情况几乎不会去讨论，所以习惯上大家会把不一致称为“弱一致”。相对的，一致就叫做“强一致”了。以一个一主两备的MySQL集群为例，“强一致”的交互过程如下：在该模式下，主库与备库同步 binlog 时，主库只有在收到两个备库的成功响应后，才能够向客户端反馈提交成功。显然，用户获得响应时，主库和备库的数据副本已经达成一致，所以后续的读操作肯定是没有问题的，这就是状态视角的“强一致”的模型。但是状态视角的这种强一致副作用很大：第一个是性能很差，主库必须要等备库1和备库2成功返回后才能返回；第二个是可用性问题，如果主备节点很多，出现故障的概率非常高。因此，状态视角的强一致代价非常大，所以很少使用。（2）操作视角状态视角的强一致降低了系统的可用性，因此很多系统选择状态视角的弱一致性模型，通过额外的算法（如Raft、Paxos）在不保证所有节点状态的一致的情况下，来保证操作视角的一致性，同时提高了系统的可用性。通过加入一些限定条件，衍生出了若干种一致性模型：线性一致性：操作视角实现真正的强一致顺序一致性：一致性强度弱于线性一致性因果一致性：一致性强度弱于顺序一致性写后读一致性：一致性强度相当，弱于因果一致性这些一致性模型的介绍参考《高斯Redis与强一致》这篇文章。3.强一致的刚需场景上一节我们介绍了什么是强一致，这一节我们介绍下强一致的典型应用场景。在常见的互联网应用中，如果数据库服务器只部署在单个节点上，那么应用程序所有的读和写都只会访问单个节点，一份逻辑数据在物理上也只有一份，这种场景下就谈不上强一致的问题。但是随着系统中业务访问量的增加，如果是单机部署数据库，就会导致I/O访问频率过高，数据库就会成为系统的瓶颈。此时，为了降低单机磁盘的I/O访问频率，提高单个机器的I/O性能，通常会增加多个数据存储节点，形成一主一从或者一主多重的架构，此时，我们可以将负载分布在多个从节点上，一方面可以实现读写分离，写请求访问主库，读请求访问备库。另一方面，还可以在主库如果出现宕机的情况下进行主备切换，增强系统的稳定性。在以上两个场景中，由于一份逻辑数据在物理上有多个副本，那么如何保证多个副本之间的数据一致呢，这就是强一致需要解决的问题。3.1 读写分离场景以关系型数据库MySQL为例，典型的部署方案为一主两从三节点方案，主节点负责处理写操作，两个从节处理读操作，分担主库的压力，如下图所示：此时，如果系统没有实现强一致，就有可能会遇到执行完写操作后，立刻去读，然后发现读不到或者读到旧状态的尴尬场景，比如操作顺序为以下操作：客户端首先通过代理向主节点 Master 进行了写入操作，此时由于没有实现强一致，写操作写完后立即返回；紧接着第二步去从节点 Slave A 执行读操作，此时Master和Slave A之间的同步还未完成，系统处于非强一致的状态，所以第二步的读操作读取到了旧状态。可以看出，在一主多备读写分离的场景下，如果想要保证写入和读取操作的准确无误，系统实现强一致是非常重要的。3.2 主备切换场景主备切换的场景也需要强一致来保证，以目前业内使用最广泛的内存数据库Redis为例，Redis的主从同步如下图所示：复客户端命令的执行结果，并不等待命令同步到从服务器再回复，也就是说Redis的主从同步其实是异步的。由于Master节点存在宕机的可能，在这种情况下，如果在Master收到命令但是还没同步到Slave服务器时发生了宕机，Redis就会发生主备切换，然后此时Master服务器和Slave服务器的数据还没有同步，就导致了数据丢失的情况。可见，开源Redis弱一致性本身的缺陷和不足，而要解决这个问题，必须实现强一致性才能解决。4.高斯Redis强一致由于开源的Redis不具备强一致的特性，导致开源Redis的应用也受到了诸多限制，为了解决开源Redis弱一致的问题，GaussDB(for Redis)应运而生。GaussDB(for Redis) 是华为云数据库团队自主研发的兼容Redis协议的云原生数据库，彻底解决了开源Redis一致性问题带来的痛点。4.1 高斯Redis架构高斯Redis的整体架构如下：相比开源Redis，高斯Redis采用存算分离的设计思想，计算层负责计算和协议的处理，聚焦服务。而存储层负责副本管理、扩缩容等处理，聚焦数据本身。高斯Redis的优势如下：数据强一致：存储层使用分布式存储DFV，轻松实现了3副本强一致；超可用：N个节点的集群最多可以挂掉N – 1个节点；低成本：数据采用磁盘存储并且进行压缩，每GB的成本不到开源Redis的十分之一；秒扩容：计算层仅需修改路由映射，无需数据搬迁，实现秒级扩容；自动备份：高斯Redis可以实现MVCC快照备份和定期自动备份。4.2 高斯Redis强一致的实现开源Redis和高斯Redis的架构如下图所示：开源Redis或者传统的主从结构如左图所示，如果在读写分离的场景或者主节点出现宕机发生主从切换的时候，都会导致数据不一致的情况。高斯Redis采用存算分离的架构，如右图所示，在存储层DFV的副本管理中采用分布式共识算法实现了3副本的强一致。计算层调用存储层的接口时，如果返回OK，那么即表示存储层已经实现副本强一致的复制。5.结语我们在做架构设计的时候，其实很多场景都隐藏着强一致的诉求。如朋友圈这类应用，如果没有实现强一致，朋友圈的评论很容易乱序。再比如限流器的场景，如果没有强一致的保证，也极容易造成数据库的崩溃。因此，必须在系统设计之初就认识到强一致的重要性，才能设计出更加稳定和可靠的系统。而高斯Redis基于存算分离的架构设计，实现了数据的强一致，为业务的稳定可靠提供了超强保障。6.附录本文作者：华为云数据库GaussDB(for Redis)团队杭州/西安/深圳简历投递：yuwenlong4@huawei.com更多产品信息：GaussDB(for Redis)官网更多技术文章：GaussDB(for Redis)博客

云计算的飞速发展，促使各行各业加快数字化转型的步伐。数据库作为信息系统核心服务，在云化的浪潮中，逐渐发展出云数据库的技术路线，不断地迭代创新。数据库产品形态演进纵观数据库行业发展历程，从早期的单机MySQL到近年来分布式数据库、NoSQL系列，数据库始终秉承着一个理念——把简单留给用户，把复杂留给数据库。1.单机早期，为了弥补单机MySQL扩展性，用户要在业务层做分库分表、读写分离。但随着数据规模持续增长，用户业务、运维负担过重。2.分布式、NoSQL随后，分布式数据库开始流行。这一代数据库数据容量大，还能够水平扩展，同时也提高了可用性。而NoSQL系列的出现，也让业务设计更加灵活。例如，Redis的key-value数据结构，搭配内部的sorted set，非常适合搭建游戏排行榜；MongoDB作为最流行的文档数据库之一，能够帮用户便捷存储json文本。3.云原生、存算分离伴随用户的业务需求复杂化，诸如“当访问量小，但数据量巨大，加上核心数据不能丢。此时只是想增加些存储空间”，传统分布式架构便“不再完美”。如今，我们已进入崭新的云原生时代。走在行业前沿的数据库产品都在进行新一轮演进，拥有更强大、更灵活的全新架构——存算分离。以企业级Redis——GaussDB(for Redis)为例，图中展示存算分离的本质：资源解耦，按需使用。“计算不足扩节点、存储不够扩容量”，这种分层、弹性的扩容机制，也为用户节省很多不必要的开销。此外，在完全兼容Redis之余，GaussDB(for Redis)也兼顾了轻量级场景——用户可随时下单8GB规格实例，使用低成本、稳定可靠的企业级Redis。GaussDB云原生带来的价值基于用户常见的4大类业务痛点场景，华为云GaussDB数据库基于存算分离架构，给出了它的解法。1.数据写满了急需扩容随着企业规模扩张，更大的算力需求、更多的存储容量需求是必然的。例如在游戏开服、11.11大促抢购高峰期间，数据量爆发性增长，此时需要对数据库进行扩容，而且在不少的业务场景下，扩容的速度甚至要求达到“用户0感知“的级别。而开源Redis由于资源以节点为单位，扩容只能计算、存储一起扩，资源浪费是一方面，还不得不做数据跨节点拷贝，耗时长。其实不少用户在扩容时，还可能面临着时间无法评估的尴尬。存算分离数据库不仅拥有秒级扩容的优势，还能满足用户“算力不足扩节点、容量不足扩容量”的要求，完全不必担心资源“买多”问题。2.节点宕机导致数据长时间不可用，业务受损单机数据库一旦宕机，全量数据不可用，只能等待数据库重启，导致业务受损严重。传统分布式数据库一旦部分数据分片故障，会导致一段时间内部分数据无法访问，依然对业务产生不小影响。存算分离数据库能够解决极端场景下的数据可用性问题。由于存储池有“共享”的性质，当部分计算层节点故障时，其他健康节点可以立刻接管“本不属于自己”的数据，让业务只感受到秒级抖动，即可继续访问全量数据，不必等待故障节点的“复活”。3.高峰期间，数据库写入拥塞业务高峰是每一个企业关注的关键场景之一。开源Redis集群虽然比简单的主+备更能应付并发访问，但面对大量写入，依然会力不从心。一是因为它的节点是单线程做命令处理的工作，容易发生请求阻塞。二是由于备节点只读，因此它的集群中仅半数节点可写，抗写能力不足。GaussDB(for Redis)抗写能力极强，能从容应对企业最关心的业务高峰。首先，它采用了多线程做命令处理的设计，单点不易发生请求阻塞。其次，在存算分离的架构优势下，实例中并不存在主备关系，全部节点都可写，吞吐能力强。4.数据库成本难降分布式存储池将存储以细粒度提供给用户，相比一块块独立硬盘低效率使用，GaussDB存储池成本会极大降低。另外，相比开源Redis纯内存设计，GaussDB(for Redis)全量数据下沉到存储池中，从根本上解决了纯内存硬件价格昂贵问题。11.11上云嘉年华之际，华为云数据库给用户提供低至0.05折的大幅折扣，包括：7200元上云大礼包，新用户首购云数据库MySQL、PostgreSQL等产品年付低至11.11元，GaussDB系列产品包年、包月4折，其中GaussDB(for Redis)小规格给出了19.9元/6个月的惊喜优惠。让用户在业务数字化转型，数据上云之初，便能感受到一剂强心剂——“成本控制不是难题，稳定可靠依然有保障”。戳此直达体验>> https://activity.huaweicloud.com/dbs_Promotion/index.html

9月8日，华为云GaussDB(for Redis)正式推出全新版本。新版本内核带来性能提升、无损升级、慢日志统计等多维度产品体验，同时推出Lua脚本和SSL连接加密两大重要功能，让业务设计更加灵活，公网访问更安全。GaussDB(for Redis)是华为云推出的企业级分布式KV数据库，它完全兼容Redis协议，提供丰富的数据类型，同时基于云原生存储计算分离架构，在成本、可靠性等方面为企业带来全新价值，此番推出的两大功能特性更是为企业业务发展带来全新体验。Lua脚本功能：业务设计更灵活GaussDB(for Redis)推出的Lua脚本功能，支持用户预设逻辑，组合执行多条命令，让业务设计更加灵活。使用方法上，GaussDB(for Redis)的Lua脚本功能与开源Redis保持完全兼容。用户可以将一组命令编入Lua脚本，交给GaussDB(for Redis)执行，从而实现原子操作的效果。相比开源Redis Cluster，GaussDB(for Redis)的Lua脚本功能更为优秀：脚本执行不易引发请求阻塞：这是由于GaussDB(for Redis)实例内部有着更细粒度的数据分片，同时每个分片都有多线程执行命令的能力。消除“脚本复制”的副作用：开源Redis主从脚本复制让时间模块、随机命令等功能受限，GaussDB(for Redis)内核采用全新实现，并无此类限制，业务设计更轻松。强一致保障：在高并发场景，GaussDB(for Redis)提供数据强一致保障，业务多点访问不会发生脏读。根据以往经验，Lua脚本在一些业务场景起着关键作用，例如：订单系统要求用户余额不出现负数，库存系统要避免商品超卖……它们都需要使用Lua脚本来确保“查询+扣减”的原子性语义。GaussDB(for Redis)将Lua脚本与强一致特性结合，给业务设计带来极大灵活性。SSL连接加密功能：公网访问更安全GaussDB(for Redis)提供的SSL连接加密功能，支持客户端使用SSL协议连接数据库，提升公网访问安全性。用户只需从华为云控制台下载证书，并使用支持SSL协议的客户端（例如Redis-cli 6.0），即可与实例建立安全可靠连接。通过控制台，用户还可以随时开启或禁用SSL连接模式。当连接模式发生切换，旧连接会被断开以确保实例网络安全。相比开源Redis 6.0 SSL，GaussDB(for Redis)保持兼容并带来以下优势：性能更好：开启SSL后的性能损失更小，约15%；而开源Redis损失更多。多线程完美兼容：开启SSL不影响多线程并发能力，而开源Redis的SSL与多线程存在二选一冲突。在一些场景中，业务有从公网甚至海外访问数据库的需求。此时，对于核心数据存储，全链路的安全保障尤为重要，新版GaussDB(for Redis)能够极大提升公网访问安全性。GaussDB(for Redis)核心价值作为云原生KV数据库，GaussDB(for Redis)有着全面领先于开源Redis的能力：成本降低75%以上：全量数据落盘，容量利用率高高稳定性：即使N-1节点故障，全量数据依旧可用高可靠性：数据三副本冗余存储，无丢失风险强一致性：强一致性保障，多点访问无脏读问题强抗写能力：全部节点可写，多线程设计强扩展能力：节点分钟级、容量秒级扩容目前GaussDB(for Redis)已经凭借出色的产品实力在游戏系统、电商平台、推荐系统、社交媒体、物联网等众多企业级应用场景中发挥巨大作用。新推出的Lua脚本和SSL连接加密两大功能特性，更是为企业数字化转型注入了全新动力。想体验更多产品能力，欢迎前往华为云官网：https://www.huaweicloud.com/product/gaussdbforredis.html

 9月3日-7日，以“数字开启未来，服务促进发展”为主题的2021中国国际服务贸易交易会（简称服贸会）在北京举行。华为云GaussDB首次亮相大会，并在会上展示了GaussDB云原生创新技术及金融行业的数字化探索和实践，积极打造坚实的数字人民币数据处理底座，推动千行百业数字化发展。2021服贸会华为云GaussDB展区图 聚焦金融领域，打造坚实的数字人民币数据处理底座 与往届不同的是，今年服贸会聚焦行业热点和发展趋势，突出数字经济和数字贸易，在开幕会上，国家决策者还宣布设立北京证券交易所，打造服务创新型中小企业主阵地。这对于深化金融改革，促进科技与资本融合，推动金融创新发展具有重要意义。 作为服务过众多企业数字化转型的利器，华为云GaussDB早在2019年11月，中国人民银行数字货币研究所与华为签署的合作备忘录中，作为数字货币的坚实数据处理底座参与金融科技建设。华为云GaussDB面向金融行业提供了一系列企业级能力，并希望借助服贸会这一国际平台，与更多来自国内外的伙伴交流分享，助力数字领域的全球化合作和数字经济社会的发展，同时响应国家号召，为数字人民币提供坚实的数据处理底座，为企业提供创新型数字服务。 以云原生技术为抓手，推动金融行业数字化转型 华为云GaussDB是华为基于金融政企经验、华为内部流程IT与云底座深耕10年以上的数据库内核研发优化能力，结合云原生与AI技术倾力打造的金融级分布式数据库，满足客户对高性能、高扩展、高可用、高安全的要求，广泛应用于金融、电力、政府、智慧城市等领域。 高性能：具备企业级复杂事务混合负载能力，支持极佳的线性弹性扩展。在银行实测中，GaussDB通过单节点Numa-Aware和分布式GTM-Lite技术，32节点处理能力达1500万tpmC；基于云原生分布式优化器以及节点/算子/指令全并行架构，复杂查询时延降低82%；而且在1000+节点超大分布式集群弹性扩展方面有很好的线性性能提升。 高可用：通过Switch Turbo技术，实现在同城AZ（可用区）内、同城AZ之间、以及异地跨Region之间快速切换，数据0丢失，满足金融级两地三中心高可用诉求。 高安全：基于业界首个纯软全密态数据库技术，实现了数据在内存中的运算态加密，保证全链路数据安全、数据主权遵从以及应用透明。 华为云GaussDB当前已经助力国有银行在其核心交易系统、渠道以及办公系统中完成分布式改造，保障业务安全合规，支持跨AZ/Region容灾；同时利用华为云UGO（数据库和应用迁移）+DRS（数据复制服务）数据迁移组合解决方案，帮助降低了70%存储过程改造成本，极大加速了银行等金融企业的数字化转型进程。 成功不是一蹴而就的，在GaussDB能力背后，是华为在数据库领域布局全球研究、软硬能力协同、坚持10+年战略投入的结果。展望未来，华为公司有能力、有信心在数据库和数据赛道传承华为优良传统，打造以“解决客户实际问题”为原则的世界级产品，助力金融领域数字人民币高质量发展及企业快而好地完成数字化转型，实现互利共赢，共享服务贸易发展机遇，共促数字贸易发展。更多GaussDB详情了解，欢迎前往华为云官网：https://www.huaweicloud.com/product/dbs.html

云数据库GaussDB(for Redis)介绍页入口，详情请点击链接云数据库GaussDB(for Redis)成长地图入口，详情请点击链接小云妹又来啦，生命不息，学习不止，今天要着重介绍的是我们的——云数据库GaussDB(for Redis)有着稳定、可靠的企业级产品定位，它完全兼容开源Redis，还能为企业带来降本增效的重要价值。稳定实用就是我~~~

云数据库GaussDB(for Redis)介绍页入口，详情请点击链接云数据库GaussDB(for Redis)成长地图入口，详情请点击链接小云妹又来啦，生命不息，学习不止，今天要着重介绍的是我们的——云数据库GaussDB(for Redis)有着稳定、可靠的企业级产品定位，它完全兼容开源Redis，还能为企业带来降本增效的重要价值。稳定实用就是我~~~

一、推荐偏差引发的思考七夕过后，笔者的一个朋友遇到了尴尬事：当女友点开他的购物APP，竟然自动弹出一系列推荐：玫瑰包邮、感动哭了、浪漫小夜灯……回想七夕那天，礼物并没有出现，于是问题出现了：从实招来，你送谁了？为了帮助友人重建信任，笔者进行了一番技术调研：这一定是“推荐系统”出了偏差。推荐系统是一种信息过滤系统，它能够快速分析海量用户行为数据，预测出用户喜好，从而进行有效推荐。在商品推荐、广告投放等业务中，推荐系统责任重大。根据亚马逊2019年度报告，其40%的营收来自内部稳定的推荐系统。在本文开篇的例子中，正是由于推荐系统问题，才导致了尴尬的场面。笔者决定力挺友人，用可靠的知识让人信服！二、推荐系统长什么样通常来说，在一套成熟的推荐系统中，分布式计算、特征存储、推荐算法是关键的三大环节，缺一不可。下面介绍一类完整的推荐系统，在系统中GaussDB(for Redis)负责核心的特征数据存储。该系统也是华为云诸多客户案例中较为成熟的最佳实践之一。第一部分：获取特征数据原始数据采集点赞、收藏、评论、购买……这些行为都属于原始数据，他们随时都在发生，因此数据量庞大。经由Kafka、Redis Stream等流组件向下游传递，或存入数仓，等待后期提取使用。分布式计算原始数据离散、含义模糊，无法直接给算法使用。此时就要进行大规模的离线、在线计算，对数据加工。Spark、Flink都是典型的大数据计算组件，其强大的分布式计算能力是推荐系统不可或缺的。特征数据存储经过加工的数据也就是特征、标签，是推荐算法所需的宝贵数据源。在特定场景下，也可以称之为用户画像、物品画像。这部分数据有着反复共享、复用的价值，不仅能用于训练算法模型，还能为生产环境提供服务。确保特征数据的可靠存储，是推荐系统中极为关键的一环。第二部分：消费特征数据线下模型训练有了关键的特征数据，业务就可以开始训练算法模型。只有充分利用特征库，以及最新行为数据，不断打磨推荐算法，这样才能提升推荐系统整体水平，最终带给用户更好的体验。线上推理预测算法模型训练结束后，将被部署到线上生产环境。它将继续利用已有的特征存储，根据用户的实时行为进行推理，快速预测出与用户最匹配的优质内容，形成推荐列表，并推送给终端用户。三、推荐系统的存储难题很显然， “特征数据”在整个系统中起到了关键的衔接作用。由于KV形式的数据抽象与特征数据极为接近，因此推荐系统里往往少不了Redis的身影。在上述系统的方案中，数据库选型为GaussDB(for Redis)，而不是开源Redis。原因是开源Redis在大数据场景下还是存在显而易见的痛点：1. 数据无法可靠存储推荐系统其实希望既能使用KV数据库，又能放心将数据长久保存。但开源Redis的能力更侧重于数据的缓存加速，而不是数据存储。而且开源Redis毕竟是纯内存设计，即使有AOF持久化，但通常也只能秒级落盘，数据的保存并不可靠。2. 数据量上不去，成本下不来涉及推荐的业务往往用户体量也不会小，随着业务发展，也会有更多的特征数据需要保存。实际上，相同容量的内存与极速SSD相比，价格贵10倍以上都很正常。于是，当数据量达到几十GB、几百GB，开源Redis会变得越来越“烧钱”，因此一般只当做“小”缓存使用。除此之外，开源Redis自身fork问题导致容量利用率低，硬件资源有很大的浪费。3. 灌库表现不佳特征数据需要定期更新，往往以小时或天为周期进行大规模数据灌入任务。如果存储组件不够“皮实”，大量写入造成数据库故障，将导致整个推荐系统发生异常。这就可能造成开篇提到的尴尬用户体验。开源Redis抗写能力并不强，这是由于集群中有一半节点是备节点，它们只能处理读请求。当大批量写入到来时，主节点容易出问题，引发连锁反应。理论上，架构设计并不是越复杂越好，如果可以，谁不想使用一种既能兼顾特征数据KV类型、成本友好、性能又有保障的可靠数据存储引擎？四、相见恨晚，遇见GaussDB(for Redis)与开源Redis不同，GaussDB (for Redis)基于存算分离架构，为推荐系统这一类大数据场景带来关键的技术价值：可靠存储：数据命令级落盘，在底层存储池中三副本冗余存储，真正做到了0丢失。降本增效：高性能持久化技术+细粒度存储池,帮助企业将数据库使用成本降低75%以上。抗写能力强：多线程设计+全部节点可写，抗写能力足够强大，从容应对Spark灌库压力和实时更新。华为云企业级数据库GaussDB (for Redis)提供稳定、可靠的KV存储能力，正是推荐系统核心数据的极佳选型。五、完美衔接，实现想存就存的自由其实，在Spark后端接入Redis已经成为一种主流方案，而使用Flink从Redis中提取维度表也是很常见的用法。它们也都提供了用于接入Redis的连接器。GaussDB(for Redis)完全兼容Redis协议，即开即用,用户随时都可以快速创建实例并接入业务。1. Spark-Redis-ConnectorSpark-Redis-Connector完美实现了Spark RDD、DataFrame到GaussDB(for Redis)实例中String、Hash、List、Set等结构的映射。用户可使用熟悉的Spark SQL语法轻松访问GaussDB(for Redis)，完成特征数据灌库、更新、提取等关键任务。使用方法非常简单：1）当需要读取Hash、List、Set结构到Spark RDD时，分别只用一行即可搞定：2）而当推荐系统进行灌库或特征数据更新时，可以按如下方式轻松完成写入：2. Flink-Redis-ConnectorFlink这款计算引擎流行程度不亚于Spark，它同样有成熟的Redis连接方案。使用Flink提供的Connector或结合Jedis客户端，都可轻松完成Flink到Redis的读写操作。以使用Flink统计单词频次的简单场景为例，数据源经过Flink加工后，便可轻松存入GaussDB(for Redis)中。六、结语大数据应用对核心数据的存储有着很高的要求,云数据库GaussDB(for Redis)拥有存算分离的云原生架构，在完全兼容Redis协议的基础上，同时做到了稳定性、可靠性的全面领先。面对海量核心数据存储，它还能为企业带来相当可观的成本节约。面向未来，GaussDB(for Redis)极有潜力成为下一个大数据浪潮的新星。七、附录本文作者：华为云数据库GuassDB(for Redis)团队杭州/西安/深圳简历投递：yuwenlong4@huawei.comGaussDB(for Redis)产品主页：https://www.huaweicloud.com/product/gaussdbforredis.html更多技术文章，关注高斯Redis官方博客：https://bbs.huaweicloud.com/community/usersnew/id_1614151726110813