>摘要：高斯Redis即保留了开源Redis的能力，同时凭借其存算分离的架构，在成本、稳定性、可靠性、一致性等方面做出了新的突破，也更加适用于当下数据规模庞大的互联网业务。本文分享自华为云社区[《【大厂内参】第12期：技术架构+应用场景揭秘，为什么高斯Redis比开源香？》](https://bbs.huaweicloud.com/blogs/308547?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=other&utm_content=content)，作者：华为云社区精选。 点的外卖总能让离店近的外卖小哥送来，双11秒杀结束后产品能立刻下架，12306火车票保证从来不超卖，微博下拉就能刷新出好友动态……这些日常碎片的背后都有着Redis的身影。 提起Redis，互联网从业者无人不知，无人不晓。毕竟，开源Redis作为一款经典的“缓存”产品，能支撑众多业务架构搭建，在游戏、电商、社交媒体等行业中发挥着重要的作用，广受开发者青睐。 然而近年来，随着各行业规模逐渐扩大，几乎只能依附于关系型数据库的传统“缓存”逐渐难以支撑上层业务，越来越力不从心。 一旦业务规模扩大后数据量逼近内存上线，开源Redis轻则发生重要数据逐出，重则导致节点OOM宕机。而且开源Redis为了访问快速，全部数据都保存在内存中，其独有的fork机制，更让平时的内存使用不得高于50%，使得内存价格一直居高不下，导致部署成本非常高。 为了解决这些难题，华为云推出了自研的企业级Key-Value数据库——云原生分布式数据库[GaussDB(for Redis)](https://www.huaweicloud.com/product/gaussdbforredis.html?utm_source=goujian&utm_medium=database&utm_content=content)（下文简称**高斯Redis**），让开发者用更低的成本构建依赖缓存的应用，且性能更高，运行更稳定。**本文将从高斯Redis的技术架构和应用场景出发，一一道来为什么高斯Redis比开源香，以及它是如何做到又快又好的。** # 开源不够，自研顶上 开门见山，先看看开发者最关心的性能和成本。如下图所示，与开源Redis相比，高斯 Redis在**成本、可用容量、吞吐、压缩上**都有非常大的优势：  注：比较相同数据容量（约200G）的成本开销 核算下来，高斯Redis以1/4的价格拥有10倍以上的可用空间，整体成本相当于是开源Redis自建数据库的1/40，这里还不包括自建Redis数据库需要额外的搭建、运维、监控、升级扩容等各项成本。 同样，对比高斯Redis和开源Redis集群在X86架构下的性能测试，结果显示，它能较开源Redis集群能提供**更高的QPS，更低的访问延迟，以及更低的数据存储成本**。 性能优势：在相同测试条件下，高斯Redis的QPS较开源Redis集群提高了11%~19%，平均延迟和P99比Redis集群降低了70%以上，p9999比Redis集群降低了15%以上。 抗写优势：在数据量大于内存的写测试中，原生Redis集群因内存限制而OOM，高斯Redis依然可以提供不俗的性能服务，它的可用的存储空间由底层SSD大小决定的，相比原生Redis集群抗写优势显著。 据存储成本更低：高斯Redis提供了高效的数据压缩服务，其占用的存储空间只有开源Redis集群的十分之一，相当于数据存储成本降低了10倍。 那么，高斯Redis的优势源自什么？从它的架构中或许可以窥见一斑。 # 存算分离，突破瓶颈 高斯Redis有两个跟业界完全不一样的特性，**第一个便是独有的存算分离架构**， 计算层实现热数据缓存，存储层实现全量数据的落盘，中间通过RDMA高速网络互连，通过算法预测用户的访问规律，实现数据的自动冷热交换，最终达到性能提升。 该架构基于华为内部的**自研分布式共享存储池**， 它也是华为全栈数据服务的基石，比如文件EVS、对象存储OBS、块存储，还有数据库族、大数据族都依赖于此，可想它的强大及稳定性。  高斯Redis基于共享存储池实现了一套Shared Everything的云原生架构，充分发挥了云原生的弹性伸缩、资源共享的优势，使得它具备强一致、秒扩容、低成本、超可用等特性，完美避开了开源Redis的主从堆积、主从不一致、fork抖动、内存利用率只有50%、大key阻塞、gossip集群管理等问题。 至于高斯Redis的存算分离架构的设计和实现原理，在线课程[当Redis遇见计算存储分离](https://education.huaweicloud.com/courses/course-v1:HuaweiX+CBUCNXD057+Self-paced/about?utm_source=goujian&utm_medium=database&utm_content=content)中有更详细的解读，包括软件架构的剖析，计算层的模块的分工，组网的设计以及容灾架构等等。 在存算分离的架构下，高斯Redis的优势可以总结为：强一致、高可用、弹性伸缩、高性能。 ### 强一致 高斯Redis将全量数据下沉到强一致的共享存储池，得益于共享存储池的3副本机制，因此写入高斯Redis的数据，在客户端收到回复时，数据也将是**3副本强一致**的，保证宕机的时候数据不会丢失，从而为业务提供前后一致的状态，再也不用担心主从切换后的数据一致性和丢失问题。 ### 高可用 其次是**高可用**，受益于分布式共享存储池，高斯Redis的每个计算节点都可以看到并共享所有数据，当某一个计算节点发生故障挂掉，其维护的slot路由信息，会被剩下的节点自动接管。由于不涉及底层数据的迁移，这个接管过程非常快。所以**N个节点下，最多可以容忍挂掉N-1个节点**。 ### 弹性伸缩 再就是弹性伸缩带来的**秒扩容能力**，实现按需扩容计算和存储。计算资源的扩容只涉及到元数据的修改，把相应的slot路由信息迁移到新的节点上，迁移速度非常快。由于采用的共享存储，大多数情况下存储扩容只要进行逻辑扩容，不涉及数据的搬迁，在后台修改存储配额即可。 ### 高性能 存算分离的架构看似比较重，链路比较复杂，实则在硬件采用、软件优化上，可以做的更大胆更激进，比如RDMA网络、用户态协议、持久化内存等等。因此受益于这些专属的存储设备，加上计算层全负荷分担架构（不引入从节点，因此性能轻松翻倍），对比同类商业数据库产品，在数据量大于内存的存储场景下，高斯Redis的性能表现很好。另外，对比开源Redis，在数据小于内存的点查场景下，高斯性能也有很大优势。 **第二个特性是多模架构带来的产品使用便捷性**。高斯Redis是多模数据库Gauss NoSQL的一员，Gauss NoSQL提供了全栈的分布式KV引擎、用户态文件系统、存储池等技术，只需要在接口上封装Redis协议，即可轻松实现一个全新的NoSQL产品。类似的，华为还提供了MongoDB、Cassandra、Influx等NoSQL引擎。 也正是得益于高斯Redis的独特优势，使得它在一些典型的应用场景下，能够应对各种突发情况，最大化发挥出Redis的特性。 ## 互联网业务神器，支撑海量存储场景 Redis最常见的应用场景是缓存，用来存放秒杀、热点事件的数据，比如微博热搜。同时，凭借其优异的存储能力，缓存场景之外的诸多应用Redis也可以轻松应对，比如 **流**： feed、消息队列、IM聊天、IoT心跳上报； **只读状态**： 历史订单、日志审计、归档信息、历史轨迹、消费记录、物流详情； **可变状态**： BI报表、金融风控、智能客服、广告推荐、标签工程、用户画像、地理位置、路径规划、知识图谱等。 下面，以其中的一些场景为例，具体看看高斯Redis到底有多强大？ # Geo 饭点时打开大众点评查看附近的餐馆，外卖小哥根据距离远近来决定配送的路径规划……这些都依靠LBS服务，它的实现又需要Redis来存储地理位置数据。但开源版本Redis因为内存限制，一直没有大规模应用支持地理位置信息存储管理的Geo功能。 高斯Redis使用磁盘替代内存，解决了这些难题，它的Geo功能适用于数据量大、读写频繁的场景，可以应对诸如外卖平台、点评平台、找房平台中，随着用户增长而对应的地理位置信息的数据量的增长，最高可达TB级别。以下图为例，可以看到在高斯Redis支持下，外卖系统可以使用Geo的相关命令，让用户获取骑手的实时位置，骑手也能找到附近可配送的订单，最终顺利将用户的外卖送到用户。  # 计数 社交平台每条热搜记录的搜索量数值；用户注册一个帐号后，网站记录的关注数、粉丝数、动态数；一个接口一分钟被限制100次请求等。这些数据背后，是一个个计数器在工作。 计数是典型的强一致应用场景，比如电商在秒杀活动中，往往会搭建Redis主从集群给下层MySQL做缓存，用Redis的计数器功能抵住流量压力。 所以如果数据发生不一致，计数器就会得到错误的信息，整个数据库可能面临崩溃的危险。但原生Redis的主从同步是异步的，当主节点写入数据后，从节点不保证立刻更新数据，如果此时读取数据，读到的就是过期的旧数据，产生数据不一致问题。高斯Redis则可以把全量数据下沉到强一致共享存储池，彻底摒弃了开源Redis的异步复制机制。另外，计算层将海量数据进行分片，在故障场景下，自动进行接管，实现了服务的高可用。 # 即时通讯 即时通讯（简称IM）是一个实时通信系统，允许两人或多人使用网络实时的传递文字消息、文件、语音与视频。它最核心的是消息系统，包括聊天消息的同步、存储和检索。而消息存储库和同步库又对存储层的性能有很高的要求：要能支撑海量消息数据的永久存储，具备极高的写入吞吐能力，尽可能低的读取延迟等等。 综上，存储层的性能会直接影响到IM系统的用户体验。高斯Redis在性能和规模上可以满足IM系统对存储层的严格要求，它作为IM系统的存储层，可以将大量的随机写转换为顺序写，提升数据写入性能，再通过读缓存、bloom filter优化读取性能。 下图是一个基于高斯Redis的IM应用案例，使用的是Stream作为基本数据结构。创建一个群聊时，在Redis中对应地为该群聊创建一个Stream队列。在发送消息时，每个用户都将消息按照时间顺序添加到Stream队列中，保证了消息的有序性。  这个应用中涉及到了一种数据类型——Redis Stream，它也是一种消息队列，提供消息的落地存储功能，让每个客户端可以访问任意时刻的消息，并记录访问位置，保证消息不会丢失，以IM中的文字聊天为例，使用Stream作为中间件，实现聊天室的发言和信息查看。高斯Redis可以存储和处理大规模的Stream数据，鲁棒性强的同时成本相对更低，适用于海量消息队列的场景。所以，相较于原生Redis，是更为理想的Stream队列承载方案。 # Feed流 互联网时代，微博、抖音、头条等都在通过Feed流（信息流）将关注的好友或感兴趣的内容及时推送给用户，吸引用户的兴趣，提高产品的商业价值。Feed流系统是Feed生成者将生产的Feed经过存储分发系统传递给Feed消费者，最终以某种展现形式。 整个系统最关键的是同步存储系统，首先是内容存储模块，由它来存储最原始的内容，比如用户发的一条微博；其次是关联关系存储模块，存储的是用户之间的关系；最后是信箱模块，也叫消息传递模块 ，通过它将消息传递到每个关联用户手中。 在Feed流场景下，高斯Redis能够支撑海量消息内容的存储和低延迟访问，以及关联关系的增删查改。在同步存储系统中的信箱存储模块，高斯Redis的Stream数据结构可以实现队列能力，实现Feed流消息读取。 # 推荐系统 电商、社交等领域的推荐系统非常发达，追溯其背后技术，不外乎这三个环节：分布式计算、特征存储、推荐算法。其中，特征数据的存储起到关键的衔接作用，由于KV形式的数据抽象与特征数据极为接近，因此推荐系统里往往少不了Redis的身影。 由于开源Redis在大数据场景下的一些固有痛点，高斯Redis是不少客户首选的数据库选型。由高斯Redis负责核心的特征数据存储，提供稳定、可靠的KV存储能力。加上它的高性能持久化技术和细粒度存储池，可帮助企业将数据库使用成本降低75%以上。高斯Redis独特的多线程设计和全部节点可写，抗写能力强，可从容应对Spark灌库压力和实时更新。 而且因为高斯Redis完全兼容Redis协议，即开即用，用户可使用熟悉的Spark SQL语法轻松访问，完成特征数据灌库、更新、提取等关键任务。 与此同时，数据源经过Flink加工后，也可轻松存入高斯Redis中。 # 成为VMALL智能推荐背后的英雄 当电商平台对AI算法模型的需求越来越多，特征数据平台的统一建设是不少开发团队头疼的事情。 只有通过统一的特征数据存储，才能改变原有的“数据孤岛”，解决生产重复造轮子的窘境。 华为商城（VMALL）就有这样的困扰，VMALL使用了大量的AI和大数据技术，用来支撑智能推荐、精准营销、智能搜索、选品投放等业务的高效开展。但因为特征数据准备阶段缺乏通用平台，严重影响研发效率。 特征数据库需要承担打通线上/线下多个场景，对接批式/流式多种数据源，满足训练/推理多样消费需求，相应地对存储也提出了高要求：既能提供**低成本的海量数据存储并方便扩容**， 又能保证数据的绝对可靠和服务的高可用；既要满足**低时延的线上推理，又要满足高吞吐的线下训练**； 既能提供简洁的KV接口供下游轻松消费，又要兼容主流的批式/流式处理引擎（Spark/Flink等）供上游快速接入。 为了满足这些要求，深入调研后，VMALL大数据团队最终选择了高斯Redis作为特征数据库。  在线上推理的特征生产（抽取、处理、存储）中，特征平台会定时调度Spark作业，从各种数据仓库、数据湖中提取数据，进行特征工程处理后，存入高斯Redis。至于实时特征，则由Flink消费Kafka，或流式存储中的数据，持续更新到高斯Redis中。 在特征消费的推理环节，对于使用实时特征的场景（如实时推荐系统），由Flink从Kafka中实时取得用户请求记录，并从高斯Redis查询取得特征，将记录和特征拼接成训练样本，存储到文件中，供线下训练使用。 目前VMALL已完成一期的特征数据迁移，包括“特征生产”业务中的“Spark离线特征生产”，以及“特征消费”业务中的“线下训练Flink特征查询”。迁移后的运行结果显示，高斯Redis在业务高峰时段时延稳定，能够满足VMALL当前业务要求。其中，读平均时延0.2ms（p990.4ms），写入平均时延0.6ms（P992ms）。 费用方面，按照VMALL的特征体量测算，亿级用户，每个用户的特征数量是数K-数10K，高斯Redis一年的费用仅3W出头，如果选用社区Redis，费用在**20W+**。 综上，高斯Redis在VMALL特征工程平台建设中，起到了关键作用。它在成本，可靠性，可扩展性等方面具有优势，可作为特征数据存储的理想方案，提供企业级的稳定可靠的Redis服务能力。 # 最后 作为一款KV数据库，高斯Redis即保留了开源Redis的能力，同时凭借其存算分离的架构，在成本、稳定性、可靠性、一致性等方面做出了新的突破，它也更加适用于当下数据规模庞大的互联网业务，包括电商平台的秒杀、推荐系统、社交平台的信息流等等。本文只是简单地解读了高斯Redis的几个典型特性，更多技术细节，以及应用案例、迁移指南等可以查看高斯Redis系列合集。

Redis支持五种数据类型：string（字符串），hash（哈希），list（列表），set（集合）及zset(sorted set：有序集合)。String（字符串）string是redis最基本的类型，你可以理解成与Memcached一模一样的类型，一个key对应一个value。string类型是二进制安全的。意思是redis的string可以包含任何数据。比如jpg图片或者序列化的对象 。string类型是Redis最基本的数据类型，一个键最大能存储512MB。实例redis 127.0.0.1:8848> SET name "huaweicloud.com" OK redis 127.0.0.1:8848> GET name "huuaweicloud"实例中我们使用了 Redis 的 SET 和 GET 命令。键为 name，对应的值为huaweicloud.comHash（哈希）Redis hash 是一个键值对集合。Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。实例redis 127.0.0.1:8848> HMSET user:1 username huaweicloud.com password huaweicloud.com points 200 OK redis 127.0.0.1:8848> HGETALL user:1 1) "username" 2) "huaweicloud.com" 3) "password" 4) "huaweicloud.com" 5) "points" 6) "200" redis 127.0.0.1:8848>以上实例中 hash 数据类型存储了包含用户脚本信息的用户对象。 实例中我们使用了 Redis HMSET, HGETALL 命令，user:1 为键值。每个 hash 可以存储 232 - 1 键值对（40多亿）。List（列表）Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素导列表的头部（左边）或者尾部（右边）redis 127.0.0.1:8848> lpush huaweicloud.com redis (integer) 1 redis 127.0.0.1:8848> lpush huaweicloud.com mongodb (integer) 2 redis 127.0.0.1:8848> lpush huaweicloud.com rabitmq (integer) 3 redis 127.0.0.1:8848> lrange huaweicloud.com 0 10 1) "rabitmq" 2) "mongodb" 3) "redis" redis 127.0.0.1:6379>列表最多可存储 232 - 1 元素 (4294967295, 每个列表可存储40多亿)。Set（集合）Redis的Set是string类型的无序集合。集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。sadd 命令添加一个string元素到,key对应的set集合中，成功返回1,如果元素以及在集合中返回0,key对应的set不存在返回错误。sadd key memberredis 127.0.0.1:8848> sadd huaweicloud.com redis (integer) 1 redis 127.0.0.1:8848> sadd huaweicloud.com mongodb (integer) 1 redis 127.0.0.1:8848> sadd huaweicloud.com rabitmq (integer) 1 redis 127.0.0.1:8848> sadd huaweicloud.com rabitmq (integer) 0 redis 127.0.0.1:8848> smembers huaweicloud.com 1) "rabitmq" 2) "mongodb" 3) "redis"以上实例中 rabitmq 添加了两次，但根据集合内元素的唯一性，第二次插入的元素将被忽略。集合中最大的成员数为 232 - 1 (4294967295, 每个集合可存储40多亿个成员)。参考文章:http://www.manongjc.com/redis/redis_data_types.html

>摘要：其实开源Redis的弱一致性已经不满足很多应用场景的诉求。怎么，不信？本文分享自华为云社区《华为云企业级Redis揭秘第15期：Redis为什么需要强一致？》，作者： GaussDB 数据库。有人说，开源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）在不保证所有节点状态的一致的情况下，来保证操作视角的一致性，同时提高了系统的可用性。通过加入一些限定条件，衍生出了若干种一致性模型：线性一致性：操作视角实现真正的强一致顺序一致性：一致性强度弱于线性一致性因果一致性：一致性强度弱于顺序一致性写后读一致性：一致性强度相当，弱于因果一致性3. 强一致的刚需场景上一节我们介绍了什么是强一致，这一节我们介绍下强一致的典型应用场景。在常见的互联网应用中，如果数据库服务器只部署在单个节点上，那么应用程序所有的读和写都只会访问单个节点，一份逻辑数据在物理上也只有一份，这种场景下就谈不上强一致的问题。但是随着系统中业务访问量的增加，如果是单机部署数据库，就会导致I/O访问频率过高，数据库就会成为系统的瓶颈。此时，为了降低单机磁盘的I/O访问频率，提高单个机器的I/O性能，通常会增加多个数据存储节点，形成一主一从或者一主多重的架构，此时，我们可以将负载分布在多个从节点上，一方面可以实现读写分离，写请求访问主库，读请求访问备库。另一方面，还可以在主库如果出现宕机的情况下进行主备切换，增强系统的稳定性。在以上两个场景中，由于一份逻辑数据在物理上有多个副本，那么如何保证多个副本之间的数据一致呢，这就是强一致需要解决的问题。3.1 读写分离场景以关系型数据库MySQL为例，典型的部署方案为一主两从三节点方案，主节点负责处理写操作，两个从节处理读操作，分担主库的压力，如下图所示：此时，如果系统没有实现强一致，就有可能会遇到执行完写操作后，立刻去读，然后发现读不到或者读到旧状态的尴尬场景，比如操作顺序为以下操作：客户端首先通过代理向主节点 Master 进行了写入操作，此时由于没有实现强一致，写操作写完后立即返回；紧接着第二步去从节点 Slave A 执行读操作，此时Master和Slave A之间的同步还未完成，系统处于非强一致的状态，所以第二步的读操作读取到了旧状态。可以看出，在一主多备读写分离的场景下，如果想要保证写入和读取操作的准确无误，系统实现强一致是非常重要的。3.2 主备切换场景主备切换的场景也需要强一致来保证，以目前业内使用最广泛的内存数据库Redis为例，Redis的主从同步如下图所示：从上图可以看出，当Redis客户端向Master服务器发送一条命令时，Master服务器立即回复客户端命令的执行结果，并不等待命令同步到从服务器再回复，也就是说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的架构如下图所示：5. 结语我们在做架构设计的时候，其实很多场景都隐藏着强一致的诉求。如朋友圈这类应用，如果没有实现强一致，朋友圈的评论很容易乱序。再比如限流器的场景，如果没有强一致的保证，也极容易造成数据库的崩溃。因此，必须在系统设计之初就认识到强一致的重要性，才能设计出更加稳定和可靠的系统。而高斯Redis基于存算分离的架构设计，实现了数据的强一致，为业务的稳定可靠提供了超强保障。

【故障现象】docker 容器中运行redis无法启动，详情截图如下：【故障诊断】根据redis的日志信息提示，初步判断是配置文件的问题。【故障原因】配置文件中的内容导致redis无法启动。【解决方案】Redis will now exit to prevent data corruption. Note that it is possible to suppress this warning by setting the following config: ignore-warnings ARM64-COW-BUG。根据信息提示，即在 redis.conf 中取消这最后一条注释： ignore-warnings ARM64-COW-BUG ，再重启redis服务即可。

最基础的概念，什么是幂等性？幂等性：提交多次的情况下，结果都一样。比如数据库查询，可称为天然幂等性，即查询多次结果都一样，无需人为去做幂等性操作。但是update table set value=value+1 where id=1,每次执行的结构都会发生变化，不是幂等。inter into table(id,name)values(1,‘name’),如id不是主键或者没有唯一索引，重复操作上面的业务，会插入多条数据，不具备幂等性；所以我们在什么情景下需要确保幂等性呢？用户多次点击保存按钮用户保存成功后，返回上一页再次保存微服务相互调用，由于网络原因，导致请求失败解决方案一、token机制：1、根据业务场景，判断哪些业务存在幂等性问题，在执行业务之前先获取token，将token缓存止redis中2、调用业务接口时，将token携带过去，一般放在请求头，作为Auth认证3、服务器判断token是否存在于redis中，存在表示第一次请求，然后删除token，继续执行业务4、如果不存在，则表示反复操作，不执行业务逻辑，直接返回重复标志！结束风险性：业务执行前删除还是后删除token？如果是执行后删除，在业务执行中，未删除token，用户又点了请求进来，那么则无法保障幂等性。如果是执行前删除，在分布式下，用户快速请求2次，这时2个请求同时到redis去获取token，对比成功，同时删除，同时执行业务，那么也无法保障幂等性。so：使用执行前删除，在分布式情况下，获取，对比，删除必须确保原子性，所以要加分布式锁。二、加锁1、数据库锁select * from table where … for update2、业务层面加分布式锁将获取、对比、删除作为一个原子性的操作加锁，处理完成后释放锁，确保串行操作。三、约束数据库唯一约束：通过主键、唯一索引，确保无法重复新增同一笔数据，这就能确保幂等性

随着计算机硬件性能的提高，企业对数据保存量的要求不断提高。使用Redis能够有效减少数据库磁盘IO，减轻管理维护工作量，降低数据库存储成本。一、Redis概述概念Redis是用C语言开发的一个开源的高性能基于内存运行的键值对NoSQL数据库特征(1) 支持数据的持久化，可以将数据保存在磁盘中，重启之后可以再次加载到内存中使用(2) 支持多种数据类型，除了KV类型的数据，还支持list、set、hash等数据结构(3) 支持master-slave模式的数据备份二、Redis应用场景热点数据加速查询(主要场景)，如热点商品、热点信息等访问量较高的数据即时信息查询，如公交到站信息、在线人数信息等时效性信息控制，如验证码控制、投票控制等分布式数据共享，如分布式集群架构中的session分离消息队列三、Redis的下载和安装去官网下载redis-3.0.4.tar.gz安装包，并放入Linux中的/opt目录在/opt目录下，执行解压命令tar -zxvf redis-3.0.4.tar.gz解压完成后出现文件夹redis-3.0.4进入文件夹redis-3.0.4，在此目录下执行make && make install命令进入默认安装目录cd /usr/local/bin，此目录中有如下文件四、Redis服务的启动修改redis配置文件，vim /opt/redis-3.0.4/redis.conf启动redis服务，cd /usr/local/bin，执行redis-server /opt/redis-3.0.4/redis.conf查看服务是否启动，ps aux | grep redis-server五、Redis命令行工具六、Redis基础知识Redis采用单线程机制进行工作Redis默认拥有16个数据库，数据库编号从0开始，默认使用0号数据库使用select 数据库编号 可以切换使用的数据库dbsize 命令查看当前数据库key的数量keys * 命令查看当前数据库所有的keyflushdb 命令清空当前数据库flushall 命令清空所有数据库Redis中所有数据库使用同一个密码，默认没有密码，Redis认为安全层面应该由Linux来保证Redis中所有索引都是从0开始Redis默认端口是6379

1、客户介绍华为商城（VMALL）是华为公司旗下的自营电子商务平台，以最终用户为主要对象，提供华为手机、无线上网设备、平板电脑、配件等系列终端产品和服务，是以营造用户的移动信息生活为服务宗旨的互联网商务平台。云数据库GaussDB(for Redis)作为华为云旗下企业级Redis，致力于为客户提供稳定可靠、超高并发，且能够极速弹性扩容的KV存储服务。GaussDB(for Redis)在VMALL特征工程平台建设中，起到了关键作用。2、业务痛点       VMALL使用了大量的AI和大数据技术，用来支撑智能推荐，精准营销，智能搜索，选品投放等业务的高效开展。        随着业务的快速发展，系统对AI算法模型的需求日益增多。当前的AI开发流程中，“模型训练”和“模型部署”阶段都已经有成熟的平台支撑，唯独“特征数据准备”阶段缺乏通用平台，       导致了“线上推理和线下训练的特征数据不一致”，“各算法模型独立开发，特征生产重复造轮子”，“特征工程投入时间多（占据算法开发耗时的60%-70%）”3个关键问题，严重影响了研发效率，阻碍业务发展。为解决此问题，VMALL大数据团队开始着手建设统一的特征平台。       特征平台的核心部件是特征存储数据库，只有通过统一的特征数据存储，才能改变原有的“数据孤岛”窘境，彻底解决“不一致”，“难共享”，“效率低”3大问题。但也正是由于特征数据库需要承担打通线上/线下多个场景，对接批式/流式多种数据源，满足训练/推理多样消费需求，对特征数据库的选型提出了非常高的要求：需要找到一款数据存储服务，既能提供低成本的海量数据存储并方便扩容，又能保证数据的绝对可靠和服务的高可用；既要满足低时延的线上推理，又要满足高吞吐的线下训练；既能提供简洁的KV接口供下游轻松消费，又要兼容主流的批式/流式处理引擎（Spark/Flink等）供上游快速接入。       经过深入调研，VMALL大数据团队最终选择了GaussDB(for Redis)作为特征数据库，下面就让我们详细看看GaussDB(for Redis)是如何满足上述苛刻要求的。3、解决方案1.    特征平台使用GaussDB(for Redis)的主要流程1）特征生产（抽取、处理、存储）离线特征（静态特征）：定时调度Spark作业，从各种数据仓库、数据湖中提取数据，进行特征工程处理后，存入GaussDB(for Redis) 。实时特征（动态特征）：Flink消费Kafka，或流式存储中的数据，持续更新到GaussDB(for Redis)中。1）特征消费线上推理：模型已经部署到生产，开始承接业务，需要低时延，高并发的消费数据，从GaussDB(for Redis)中读取数据。线下训练：GaussDB(for Redis)存有最新的特征数据，OBS中存有全量的特征数据。对于使用静态特征的较为简单的模型，可以直接从OBS中获取特征使用。对于使用实时特征的场景（如实时推荐系统），由Flink从Kafka中实时取得用户请求记录，并从GaussDB(for Redis) 查询取得特征，将记录和特征拼接成训练样本，存储到文件中，供线下训练使用。2.  特征平台对GaussDB(for Redis)的核心诉求     结合上述业务场景，总结特征平台对GaussDB(for Redis)的核心诉求如下：序号类别诉求点1业务接口支持简洁的KV接口（不需要范围查询），支持和Spark/Flink快速对接，提升业务开发效率2稳定性作为电商应用的关键支撑系统，需要具备企业级应用的稳定性。如社区Redis存在的fork抖动，oom等问题，需要解决3可靠性特征数据决定了最终给客户的推荐效果，需要确保数据零丢失，强一致4成本特征数据体量庞大，希望采用内存+磁盘混合存储，降低使用成本5性能抗写能力必须强，满足特征数据批量灌库的要求；读取总体要低时延，但非缓存场景，可接受非活跃用户的时延毛刺6可扩展性随着业务发展，特征数据上量很快；扩容要简单，快速，业务影响尽量小3. GaussDB(for Redis)满足特征平台诉求的关键方案1）业务接口       GaussDB(for Redis)兼容社区Redis5.0接口，支持和Spark/Flink Connector的对接，很好的满足了业务的使用需求2）稳定性       GaussDB(for Redis)采用自研内核，解决了社区Redis的fork，oom等老大难问题，具备了企业级应用的稳定性3）可靠性数据零丢失：逐条命令实时落盘，底层三副本冗余存储，无数据丢失风险数据强一致：基于GaussDB公共的共享存储部件DFV，实现三副本强一致，多点访问无脏读风险4）成本       GaussDB(for Redis)实现数据的自动冷热分离，采用内存+SSD的混合存储方案，大幅降低了客户的使用成本。按照VMALL的特征体量测算，亿级用户，每个用户的特征数量是数K-数10K，GaussDB(for Redis)一年的费用仅3W出头，如果选用社区Redis，费用在20W+5）性能       GaussDB(for Redis)采用多线程架构，并且所有节点可以同时支持写入，因此可以较好满足批量灌库的高吞吐写需求。读方面，基于冷热分离方案，热数据常驻内存提供稳定低时延；冷数据读涉及IO交换，存在一定长尾，但可满足VMALL业务要求（目前VMALL线上GaussDB(for Redis)实例读时延平均0.16ms，P99 0.4ms，P9999 1.5ms）6）可扩展性       基于计算存储分离架构，底层数据可被任一节点访问，扩容过程不发生数据拷贝搬迁，因此速度极快；计算节点扩容分钟级完成，存储扩容秒级完成，RTO < 10秒综上，与社区Redis相比，GaussDB(for Redis)提供了更稳定的使用体验，更可靠的数据存储，更低廉的使用成本和更便捷的扩展能力，是更适合像VMALL特征平台这样大规模电商大数据应用的企业级Redis服务。因此，VMALL特征平台最终选择GaussDB(for Redis)作为特征数据的存储服务。4、上线后效果目前VMALL已完成一期的特征数据迁移，包括“特征生产”业务中的“Spark离线特征生产”，以及“特征消费”业务中的“线下训练Flink特征查询”，已迁移到GaussDB(for Redis)。当前GaussDB(for Redis)运行平稳，业务高峰时段时延稳定，能够满足VMALL当前业务要求。其中，读平均时延0.2ms（p99<0.4ms），写入平均时延0.6ms（P99<2ms）。VMALL当前已启动二期的特征数据迁移，计划完成包括“Flink在线特征生成”，“线上推理”等核心业务的接入。5、 总结本文介绍了华为商城（VMALL）在建设特征平台过程中，对特征数据存储服务的选型和应用。由此可见，华为云GaussDB(for Redis)服务在成本，可靠性，可扩展性等方面具有优势，可作为特征数据存储的理想方案，提供企业级的稳定可靠的Redis服务能力。6、附录GaussDB(for Redis)产品主页：https://www.huaweicloud.com/product/gaussdbforredis.html更多技术文章，请关注GaussDB(for Redis)官方博客：https://bbs.huaweicloud.com/community/usersnew/id_1614151726110813

华为的redis经过定制，增加了krb5认证。需要提供连接redis集群对应版本的java样例代码 经过验证，华为之前提供的文档的样例代码，依赖的第三方jar包（jredisclient-8.0.2-302002.jar）是华为基于jedis进行了定制化。        该jar包与dts依赖的jar包（jedis-3.3.0.jar）存在冲突，引用该jar包会导致DTS程序无法启动。        DTS程序使用的是springboot（版本：2.4.9）+jedis（版本：3.3.0）的方式接入redis，请帮忙协调华为的同事提供该模式接入redis的样例代码。        附件为启动的错误日志信息。

volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰no-enviction（驱逐）：禁止驱逐数据

# 华为FusionInsight MRS实战 - 使用FlinkSQL处理数据并使用redis做实时展示 ## 场景说明 【需求】计算最近1小时各个账户交易总金额。 【分析】将账户交易数据接入Kafka中，通过Flink计算过去1小时各个账户的交易总金额，将计算结果写入Redis中。做实时大屏展示。 【实现】通过FlinkSQL的滚动窗口计算 数据流图  ## 操作步骤 - 登录华为FusionInisght MRS Flink WebUI  - 在作业管理选择新建作业创建一个FlinkSQL任务  - 编辑如下Flink SQL语句 ``` CREATE TABLE kafka_source ( account varchar(10), cost int, ts AS PROCTIME() ) WITH ( 'connector' = 'kafka', 'topic' = 'redisdemo', 'properties.bootstrap.servers' = '172.16.9.117:21005', 'properties.group.id' = 'testGroup', 'scan.startup.mode' = 'latest-offset', 'format' = 'json' ); CREATE SINK STREAM redis_sink( account varchar, costs int, PRIMARY KEY(account) ) WITH ( 'isSafeMode' = 'true', 'clusterAddress' = '172.16.9.117:22404,172.16.9.118:22404,172.16.9.113:22404', 'redistype' = 'String', 'type' = 'Redis', 'isSSLMode' = 'false' ); INSERT INTO redis_sink SELECT account, SUM(cost) FROM kafka_source GROUP BY TUMBLE(ts, INTERVAL '10' SECOND), --为了快算看到计算结果使用10s窗口 account; ``` - 点击语义校验，确保语义校验通过  - 启动该Flink SQL任务  - 使用kafka客户端插入测试数据 ``` {"account": "A1","cost":"11"} {"account": "A1","cost":"22"} {"account": "A2","cost":"33"} {"account": "A3","cost":"44"} ```  注意： 因为flink窗口时间为10秒，并且redis是key value数据库，数据会根据主键覆盖，所以需要在10s内将数据全部输入 - 登录redis客户端查看结果： `redis-cli -c -h 172.16.9.117 -p 22404` 

在共享数据加速，保持数据（如订单数据）一致性的场景下，采用单主多从的缓存模式，在两个数据中心更新缓存时，是先写到一个Redis Master集群中，然后从一个Redis Master集群同步到两个数据中心的Redis Slave集群中，整个请求的逻辑就是：请求进入其中一个机房的微服务中，微服务首先会读取微服务本地的一级缓存，如果没有命中，再去本数据中心的Redis Slave集群进行查询，如果还是没有命中，再回源到本数据中心的数据库中进行查询，将读取后的数据写入到Redis Master集群，同时更新本地的一级缓存和Redis Slave集群，当然Redis Master集群也会将数据同步更新到另一个数据中心的Redis Slave集群中。这种单写多读的缓存模式实现数据加速以及保证数据一致性的要求。目前这种跨机房的主从同步延时并不明显，延迟在一两毫秒左右。在共享数据加速但不考虑数据（商品）一致性的场景下，也是采用多活的理念，即在两个数据中心部署完全对等的缓存集群。在上图的机房一中，当有数据请求时，首先从本地一级缓存进行查询，如果没有命中，再去查本地的Redis集群，依旧没有命中时，回源到本地的数据库进行查询，同时将查询到的数据更新到本数据中心的Redis集群。虽然两个数据中心的缓存集群部署一致，但是在Redis集群中存的数据可能不一致。数据层作为六层架构中的最底层，主要的应用还是基于MySQL的主从模式。下面提到的特点是在非核心业务上的一些尝试，并没有大面积应用：同城双活，即由业务层来控制数据的实时性和最终一致性，而不是通过数据同步来保证实时性和一致性。业务层双写，数据异步分发至两个数据中心，任意机房写入的数据通过异步消息的方式分发到另一个机房，以此来保证两个机房数据的最终一致性。业务层通过二级查询保证数据的实时一致性，由于业务层双写只能保证数据的最终一致性，无法保证实时一致性，因此，针对具有实时一致性要求的业务场景，我们通过业务层的二级查询来保证。 重复写入应对单机房故障，当任意机房出现故障时，如果写入的数据还没有分发至另一个机房，则由业务层在可用机房重复写入数据，通过算法来生成相同的ID。通过failover库为高可用提供双重保险，针对流水型业务数据，在数据库故障时，需要进行主从切换，此时通过业务层将所有数据的读写切换至failover库，主库恢复以后再将流量切回主库。垂直拆分与水平拆分结合使用。 服务化 之所以需要服务化，是因为在做服务化之前系统高度耦合，牵一发而动全身，直接影响到系统可用性；同时业务相互影响，系统很难维护；系统逻辑过于耦合，很难进行水平扩展；也无法通过流控、降级等手段保障系统的可用性；此外由于系统的高度耦合，极易产生雪崩效应。因此基于上述原因，服务化改造势在必行。对于服务化而言，最核心的就是服务的发现、注册、调用。目前有货采用的是Spring+Register+Zookeeper搭建的最简单的服务框架，通过Zookeeper完成的服务注册和发现，通过Register完成服务的调用。集中式的LoadBalance，在服务消费者和提供者之间通过阿里云的负载均衡或者F5搭建独立的LoadBalance，通过集中式的负载均衡设备完成对服务调用的负载均衡；在进程内做负载均衡，即软负载的方式，将负载均衡策略渗入到服务框架里面，服务消费者作为负载均衡的客户端，请求只需要从服务注册中心获取最新的服务列表，利用服务框架自身携带的负载均衡策略，完成负载均衡的调用。在服务降级方面，通过使用开源的Hystrix配置服务超时时间，当服务调用超时时，直接返回或执行Fallback逻辑。另外基于Hystrix提供的熔断器组件，可以自动运行或手动调用对当前服务进行暂停后再重新调用服务。流量控制方面，通过计数器服务限定单位时间内当前服务的最大调用次数（比如600次/分钟），如果超过则拒绝，以保证系统的可用性；同时为每个服务提供一个小的线程池，如果线程池已满，调用将被立即拒绝，默认不采用排队，加速失败判定时间。服务化中，对于服务的监控、性能优化以及调用链的分析也尤为重要。通过Hystrix提供的服务化监控工具实时观察在线服务的运行状态，有了监控之后可以进行相应的性能优化。对于调用链分析，当请求从网关层进入时，追加一个Trace ID，Trace ID会在整个调用过程中保留，最后通过分析Trace ID将整个请求的调用链串联起来。

项目背景:用户通过域名访问vip, nginx做为负载均衡为后端应用分发请求, 后端应用为dubbo服务,存储分为redis和mysql. redis做为持久会存储数据库,支持前端业力. 并且通过mq同步数据到mysql,供后端使用. 同时后台写mysql也要通过mq同步到redis.目前后端服务qps最高可以达到5万,本次架构设计在不重构的情况下短期内最快的方法达到目标10万qps.架构方案:一，现有idc架构可支撑5万qps。这是经过一年考验下来的，可做为保底的；如果应用全部上云，需要从0开始重新验证能否达到现有5万qps，再去验证能否达到10万qps，时间等未知风验很大；  二，10万qps目标，建议用简单粗暴的方式，直接把idc应用层架构复制一套上云；不建议在现有架构上继续调优，现在架构如果不重构，可能很难找到问题；与其这样不如把人力时间用到另一个方向，比如数据中心；   三，由idc+公有云两套系统构成混合云模式，数据统一使用idc的redis和mysql，公有云与idc 的数据库连接建立专线；混合云的方式可以检测公有云的实际性能，也能为将来全部迁移公有云提供真实参考；   四，平时比赛，使用idc架构完全可以支撑，公有云留少量机器和用户请求预热，重要比赛，临时增加云资源扛突发，服务器成本节约，扩展性也灵活；   五，公有云都有出现过大规模事故,造成全站不能访问的情况,为了保险，我们依然要保留idc的服务，所以混合云也许是最适合的；      技术难点：   一，如何将用户请求分流到 idc和公有云两套应用   1，域名解析两条A记录，分别指向idc和公有云两个vip，通过dns平均分配用户请求   2，idc架构在nginx前端增加四层负载均衡（lvs,ha_porxy），由四层负载均衡将用户请求转发给idc的nginx和公有云的负载均衡，lvs与公有云通信通过专线；   二，前端应用入口放大，后端数据中心，需要扩容   1，redis使用多主多从，redis3.0 还是用 代理（predixy,codis）；   2，业务拆分，组建更多的一主多从；      具体实施：   1，双系统流量分发配置lvs即可，本赛季最好能用上几轮，演练资源增减，熟悉流程，检测可行性；   2，redis数据中心需要大量的测试，选型，可做重点研究（这也是目前急需解决的单点）；

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

企业级Redis的几个典型需求:海量数据存储、高并发、服务高可用、数据高可靠Redis数据存储在内存中,服务器集群的内存已能达到T级别,能实现每秒几十万上百万级别的高并发。那么Redis如何实现数据高可靠呢?Redis不同于磁盘数据库,服务器宕机或者Redis服务关闭都会导致内存中数据丢失。因此引入Redis的持久化机制,实现灾备,数据恢复,以及服务高可用能力:借助持久化文件的增量同步,实现Redis主备高可用。将持久化文件转移存储,实现异地灾备与数据恢复能力下面简要介绍下Redis数据导出与持久化&远程导出很多场景下,我们需要将远程的Redis数据导出到本地。主要利用了Redis的持久化命令(SAVE/BGSAVE)，以及复制命令(SYNC/PSYNC）导出方式1: Redis-liRedis自带命令行工具,它支持导出RDB文件,也支持将持久化的AOF文件整库导入。导出为RDB文件命令:redis-cli -h {redis_address) -p 6379 --rdb {outputfile.rdb}开启AOF持久化命令:redis-cli -h {redis_address) -p 6379 config set appendonly yes注意:此命令会生成一个AOF文件,默认保存在Redis实例运行的安装目录导出方式2: 第三方开源工具redis-portredis-port的导出工作原理,主要是伪装成slave,利用sync命令接收RDB文件。导出为RDB文件命令:redis-dump -n 3 -m {password}@{redis-host}:{port} -o {outputfile. rdb}导出方式3:有些云厂商服务禁用了客户端发起的config/save/sync等命令,导致不能使用redis-cli或第三方工具导出RDB、 AOF文件。不过云厂商一般都提供Redis实例的备份以及备份文件下载功能。下载文件为AOF或RDB格式。

主服务器写内存快照，会阻塞主线程的工作，当快照比较大时对性能影响是非常大的，会间断性暂停服务，所以主服务器最好不要写内存快照。Redis 主从复制的性能问题，为了主从复制的速度和连接的稳定性，主从库最好在同一个局域网内。