【功能模块】系统管理 -->人员管理 -->人员群组下添加人员【操作步骤&问题现象】1、添加人员信息后，点击确认，2、问题报错：redis连接器 无法连接【截图信息】【日志信息】（可选，上传日志内容或者附件）

【功能模块】【操作步骤&问题现象】0、在管理/BO配置/Person/系统参数 中，配置了“RedisConnectorName”：1、使用人员BO新增人员：【截图信息】【日志信息】（可选，上传日志内容或者附件）

一、背景 即时通讯（Instant Messaging，简称IM）是一个实时通信系统，允许两人或多人使用网络实时的传递文字消息、文件、语音与视频。微信、QQ等IM类产品在这个高度信息化的互联网时代已成为生活必备品，IM系统中最核心的部分是消息系统，消息系统中最核心的功能是消息的同步、存储和检索。·   消息同步：将消息完整的、快速的从发送方发送至接收方。消息同步系统最重要的衡量指标是消息传递的实时性、完整性、顺序性以及支撑的消息规模。·   消息存储：即消息的持久化，传统消息系统通常支持消息在接收端的本地存储，数据基本不具备可靠性。现代消息系统支持消息在云端存储，从而实现消息异地查询：账号可在任意客户端登陆查看所有历史消息。·   消息检索：消息一般是文本，所以支持全文检索也是必备的能力之一。传统消息系统通常来说基于本地存储的消息数据来构建索引，支持消息的本地检索。而现代消息系统支持消息的在线存储以及存储过程中构建索引，提供全面的消息检索功能。二、IM系统架构设计       上图为IM系统的应用场景，可用于聊天，游戏、智能客服等诸多行业。不同行业对IM系统的成本、性能、可靠性、时延等指标的需求是不同的，架构设计需要进行平衡。接下来将介绍IM系统架构设计所涉及到的一些基本概念。2.1 传统架构 vs 现代架构 ·   传统架构Ø  先同步后存储。Ø  在线消息同步和离线消息缓存。Ø  服务端不会对消息进行持久化，无法支持消息异地查询。·    现代架构Ø  先存储后同步。Ø  划分消息存储库与消息同步库。消息存储库用于全量保存所有会话消息，主要用于支持消息异地查询。消息同步库，主要用于接收方的多端同步。Ø  提供消息全文检索能力。2.2 读扩散vs 写扩散 《2020微信数据报告》指出，截至2020年9月，微信月活跃用户数为10.825亿，日消息发送次数450亿次，日音视频呼叫成功次数4.1亿次。面临这么多的消息，如何保证消息传递的可靠性、一致性并且有效的降低服务器或者客户端的压力是十分具有技术挑战的。其中，采用何种读写模型对IM系统至关重要，这里介绍两种模型：读扩散和写扩散。        如上图所示，用户B与每个聊天的人(A1,A2,A3)都有一个信箱（一种数据结构的抽象，用于存储消息），B在查看聊天信息时需读取所有有新消息的信箱。IM系统里的读扩散通常是每两个相关联的人就有一个信箱。读扩散的优点：·   写操作(发消息)轻量，不管是单聊还是群聊，只需要往相应的信箱写一次即可。·   每一个信箱天然就是两个人的聊天记录，可以方便查看和搜索聊天记录。读扩散的缺点：·   读操作(读消息)很重，存在读放大效应。如上图，在写扩散中，用户(B1,B2,B3)都只从自己的信箱里读取消息，但写(发消息)的时候，对于单聊跟群聊处理如下：·   单聊：往自己的信箱跟对方的信箱都写一份消息；同时，如果需要查看两个人的聊天历史记录的话还需要再写一份。·   群聊：发信息时需要针对所有群成员的信箱都写一份消息。群聊使用的是写扩散模型，而写扩散很消耗资源，因此微信群有人数上限(目前是500)。写扩散优点：·   读操作很轻量，只需要读取自己的邮箱。·   可以很方便实现消息的多终端同步。写扩散缺点：·   写操作很重，尤其是对于群聊来说。2.3 推模式 vs 拉模式 vs 推拉结合模式      在IM系统中，消息的获取通常有三种模式：·   推模式(Push)：新消息到达时由服务器主动推送给所有客户端；需要客户端和服务器建立长连接，实时性很高，对客户端来说只需要接收处理消息即可；缺点是服务端不知道客户端处理消息的能力，可能会导致数据积压。·   拉模式(Pull)：由前端主动发起拉取消息的请求，为了保证消息的实时性，一般采用推模式，拉模式一般用于获取历史消息；因客户端拉取新消息的时间间隔不好预设，太短可能会导致大量的连接拉取不到数据，太长导致数据接收不及时。·   推拉结合模式：兼顾push和pull两种模式的优点。新消息来临时服务器会先推送一个新消息到达的通知给前端，前端接收到通知后就向服务器拉取消息。三、IM技术挑战 上图为IM系统的总体架构图，Client双方通信会经过Server转发来完成消息传递。其核心为消息存储库和消息同步库。这两种库对存储层的性能有极高的要求。 ·   支撑海量数据存储：对于消息存储库来说，如果需要消息永久存储，则随着时间的积累，数据规模会越来越大，需存储库支持容量无限扩展以应对日益增长的消息数据。 ·   低存储成本：消息数据具有明显的冷热特征，大部分查询集中在热数据，冷数据需要一个低成本的存储方式，否则随着时间的积累，数据量不断膨胀，存储成本会不断上升。 ·   数据生命周期管理：不管是对于消息数据的存储还是同步，数据都需要定义生命周期。存储库是用于在线存储消息数据本身，通常需要设定一个较长周期的保存时间。而同步库  是用于写扩散模式的在线或离线推送，通常设定一个较短的保存时间。 ·   极高的写入吞吐：绝大部分IM类场景，通常是采用写扩散模型，写扩散要求底层存储具备极高的写入吞吐能力，从而应对消息洪峰。·   低延迟的读：消息系统通常应用于在线场景，具备较高的实时性，读取延迟应尽可能低。四、高斯Redis在IM场景中的优势 IM系统的核心是存储层，其性能差异将直接影响IM系统的用户体验。目前存储层可选择的数据库产品有很多，如HBase、开源Redis等等。选择何种数据库，需根据业务规模、成本、性能等指标来进行综合选择。这里介绍一种NoSQL数据库：高斯Redis，在性能和规模上，可以满足IM系统对存储层的严格要求：海量数据存储、低存储成本、生命周期管理、写入吞吐大、读取时延低。4.1高斯Redis简介 高斯Redis是华为云数据库团队自主研发且兼容Redis5.0协议的云原生数据库，采用计算存储分离架构。存储侧使用自研的存储系统，容量无限扩展、强一致、高可靠。计算侧基于 LSM 存储引擎实现，通过将大量的随机写转换为顺序写，从而极大的提升了数据写入性能，同时也通过读缓存、bloom filter 等极大优化了读取性能。下图是高斯Redis在IM场景的优势介绍。4.2基于高斯Redis的IM应用案例：       下图是基于高斯Redis的IM系统模型图，这里我们使用stream作为基本数据结构。Redis stream不仅可以作为消息存储容器，还实现了生产者、消费者等基本模型，具有IM系统的基本功能，如消息订阅，分发、增加消费者等，用户可基于高斯Redis快速构建一套IM系统。创建一个群聊时，在Redis中对应地为该群聊创建一个stream队列。在发送消息时，每个用户都将消息按照时间顺序添加到stream队列中，保证了消息的有序性。stream是一个持久化的队列，可保证信息不丢失。五、总结 高斯Redis通过一系列技术创新实现了读写性能水平扩展，秒级扩容，低成本以及自动备份等功能, 可作为IM系统的存储层，其优异的读写性能和高级特性将会极大助力IM应用.同时，高斯Redis在开源Redis的基础之上，较好平衡了性能和成本，能够广泛应用在智慧医疗、流量削峰、计数器等领域。六、结束本文作者：华为云高斯Redis团队。杭州西安深圳简历投递：yuwenlong4@huawei.com更多技术文章，关注高斯Redis官方博客：https://bbs.huaweicloud.com/community/usersnew/id_1614151726110813七、参考资料1. 《GaussDB(for Redis)官方主页》https://www.huaweicloud.com/product/gaussdbforredis.html2. 《华为云GaussDB(for Redis)与自建开源Redis的成本对比》https://www.modb.pro/db/427393. 《华为云PB级数据库GaussDB(for Redis)揭秘第一期：Redis与存算分离》https://bbs.huaweicloud.com/blogs/2385844. 《华为云PB级数据库GaussDB(for Redis)揭秘第三期：一场由fork引发的超时，让我们重新探讨了Redis的抖动问题》https://bbs.huaweicloud.com/blogs/2456515. 《现代 IM 系统中的消息系统架构—架构篇》https://www.infoq.cn/article/ypb3y2lv-dsftrr5cguv

1、背景LBS（Location Based Service，基于位置的服务）有非常广泛的应用场景，最常见的应用就是POI（Point of Interest）的查询，例如用户查找附近的人，附近的餐厅，附近的外卖商家等等。LBS的实现需要数据库存储地理位置信息，开源Redis是一个功能强、效率高、使用方便的缓存数据库，实现了地理位置存储的功能，可以用于LBS的数据存储。开源Redis 3.2以上版本的Geo功能支持了地理位置信息存储管理，但是内存限制导致没有大规模应用。GaussDB(for Redis)（下文简称高斯Redis）兼容开源Redis的Geo功能，使用磁盘替代内存，突破了开源Redis的内存限制，可以完美解决Geo的大规模应用问题。2、开源Redis Geo介绍Redis的Geo功能支持如下 6 个 Geo 的相关操作：(1) geoadd：添加某个地理位置的坐标。(2) geopos：获取某个地理位置的坐标。(3) geodist：获取两个地理位置的距离。(4)  geohash：获取某个地理位置的geohash值。(5)  georadius：根据给定地理位置坐标获取指定范围内的地理位置集合。(6)   georadiusbymember：根据给定地理位置获取指定范围内的地理位置集合。Redis Geo功能的空间索引采用 GeoHash 原理，配合zset集合存储，查询效率接近 log(N)。3、为什么开源Redis Geo没有广泛应用？存储地理位置信息的应用非常广泛，而开源Redis Geo功能也可以存储地理位置信息，并且查询效率高，为什么没有得到大规模的应用呢？分析存储地理位置信息的场景，都有如下特点：1)数据量大大部分场景存储地理位置信息的数据量都是TB级以上的，开源Redis的数据全部存放在内存中，节点的内存大小固定，要支持大数据量的地理位置信息存储，必须增加节点数，这会造成成本过高、大集群维护困难等问题。2)数据持续增长随着用户的增长，地理位置信息的数据也在持续增长，要求底层存储能够无损扩容。但开源Redis扩容需要重新划分hash槽进行数据迁移，必定会影响业务。3)高并发读写开源Redis主从模式下只有主节点可写，主节点高并发数据写入、高并发数据读出，写入速度过高容易造成主从堆积，数据丢失。除此之外，还需要考虑备份恢复，数据一致性，扩容，高可用等数据库系统能力。1) 备份恢复开源Redis提供RDB和AOF方式备份数据，但当数据规模大时，RDB方式恢复的数据一致性和完整性较差，AOF方式数据恢复的效率低。2) 数据一致性开源Redis的主从采用异步复制，会出现数据不一致的情况。3) 高可用开源Redis如果同时挂掉一对主从节点，部分数据将不可用，容错能力弱。4、高斯Redis为什么合适？高斯Redis基于华为自研分布式存储系统DFV，支持PB级大规模的数据存储。解决了开源Redis高成本、存储数据量小、数据不一致等问题，具有秒扩容、超可用、强一致、低成本、自动备份、抗写能力强的优势。5、适用场景高斯Redis Geo功能适用于数据量大、读写频繁的场景。在外卖平台、点评平台、找房平台中，餐馆的数据、外卖骑手的数据、用户的数据、房源的数据这些数据随着用户增长，数据量过亿，对应的地理位置信息的数据量可到数TB级别，正是高斯Redis适用的场景。下面介绍在不同场景中Geo功能的应用。5.1外卖场景：（1）用户下完外卖订单后，使用geoadd命令加入骑手的位置。（2）使用geopos命令，用户可获得骑手的具体位置。（3）使用georadius/ georadiusbymember命令骑手查看附近可配送的订单。（4）使用geodist命令用户可获得骑手的距离。5.2点评场景：（1）新的店铺加入点评平台，使用geoadd命令，添加新店铺的位置。（2）使用geopos命令，用户获得店铺的具体位置。（3）使用geodist命令，用户可获得与店铺的距离。（4）使用georadius/ georadiusbymember，用户可查找距离500米范围的店铺。5.3找房场景：（1）新的房源加入房源平台中，使用geoadd命令，添加新房源的位置。（2）使用geopos命令，用户可获得房源的具体位置。（3）使用geodist命令，用户可获得与房源的距离。（4）使用georadius/ georadiusbymember命令，用户查找附近1km范围内的房源。6、总结开源Redis的Geo功能查询效率高，但存在存储容量小、抗写能力弱、可用性差等明显缺点，导致了其Geo功能一直没有广泛应用。高斯Redis突破了开源Redis的内存限制，以高性能磁盘存储数据，具有秒扩容、超可用、强一致、低成本、自动备份、抗写能力强的特点，因此高斯Redis适用于大量地理位置信息存储的场景。7、结束本文作者：华为云高斯Redis团队。杭州西安深圳简历投递：yuwenlong4@huawei.com更多技术文章，关注高斯Redis官方博客：https://bbs.huaweicloud.com/community/usersnew/id_1614151726110813 PS：值此开年采购季之际，企业新用户购买GaussDB (for Redis)4U16G任意存储规格，内存可享3个月3折。另外还有多款云数据库包年低至2.7折，0门槛抽千元大奖、新购满额送华为手机P40 Pro 5G等多重福利，链接：https://activity.huaweicloud.com/dbs_Promotion/index.html

 本文作者：华为云高斯Redis团队简历投递：yuwenlong4@huawei.com引言：Redis Stream是Redis 5.0引入的一种新的数据类型，其本质是一个消息队列，类似于 kafka等消息中间件。它提供了消息的落地存储功能，并实现了类似kafka消费组和消费者的功能。与kafka相比，Redis Stream同样拥有强大的功能，但因原生Redis无法有效支持大规模数据存储，成本昂贵，并存在数据丢失/不一致风险等原因，导致其未能流行起来。本文将对Stream的常用命令和应用场景进行介绍，并探讨原生Redis Stream消息队列的缺陷以及GaussDB(for Redis)提供的解决方案，供大家学习和选用。一、Redis Stream简介与Pub/Sub相比，Redis Stream 具有消息的落地存储功能，每一个客户端能访问任意时刻的消息，并且能记录每一个客户端的访问位置，还能保证消息不会丢失。Redis Stream 的结构如下所示，它有一个消息链表，将所有加入的消息都链接起来，每个消息都有唯一的 ID 和对应的内容。如图所示，每一个Stream队列包含多条消息，每条消息由唯一的ID进行标识，由时间戳和序列号组成，例如1627849609889-0。每条消息以追加的方式添加到Stream队列中。同一个Stream队列可以包含多个消费组（Consumer Group），每个消费组的状态都是独立的，同一个Stream队列的消息可以被多个消费组重复消费。 同一个消费组又包含多个消费者（Consumer），这些消费者之间是竞争关系，不同消费者不会重复消费同一条消息，任意一个消费者读取了队列中的一条消息都会使消费组中的游标last_delivered_id往前移动。该方式提高了并发效率，例如，多个进程并发处理Stream队列中的消息。每个消费者中维持一个状态变量pending_ids，简称为PEL(Pending Entries List)，记录了当前已经被客户端读取的但尚未被ACK的消息，确保消息被客户端成功消费。 Redis Stream命令可以分为消息队列命令和消费者命令两类，如下所示：以即时通讯中的聊天室场景为例，使用Redis Stream作为中间件，实现聊天室的发言以及信息查看。1）使用XADD命令进行发言。      2）使用XLEN命令获取聊天室发言的数量。     3）使用XRANGE获取消息队列的消息。     4）使用XREAD命令读取消息。可以在不设置消费组和消费者的情况下，使用XREAD的命令进行消息读取，此时Stream队列类似于一个普通的列表（list）。   更多的Redis Stream命令使用请参考官方文档（https://redis.io/commands/xread）。二、应用场景  由于Redis Stream天然有序，特别适合存储时序数据，应用场景包括即时通讯、智慧医疗、流量削峰、智慧城市等领域。（1）即时通讯：微信、QQ等是我们日常生活中常用的通讯软件，常用的聊天方式包含点对点通讯和群聊两种方式。下图是一个群聊的模型图，当采用Redis Stream作为通讯的中间件，创建一个群聊时，在Redis中对应地为该群聊创建一个Stream队列。在发送消息时，将每个用户的消息按照时间顺序添加到Stream队列中，保证了消息的有序性。由于Stream是一个持久化的队列，无论是在线还是离线状态，每个用户可以多次查看历史消息，保证了通讯的完整性。（2）智慧医疗：医疗行业的信息化，可以更好地服务于每一个人。为每一个人从出生起建立一份健康档案，记录相应的健康信息，如体检报告、诊断报告、用药信息、以及智能终端实时上传的健康指标。这些信息都是一些时序数据，同样可以采用Redis Stream来实现智慧医疗系统。建立起智慧医疗系统后，使用终端可以查看所有的医疗信息，并会提示患者按时吃药，在终端上传身体指标异常时，会自动报警并预约挂号。现阶段每个医院都有自己的信息系统，不同的医院很难查到同一个患者的医疗信息，在未来，医疗上云将有利于解决医疗信息孤岛，更好的帮助每一位患者。（3）流量削峰：在常见的秒杀活动或团购中，如春运抢票、商城促销等，通常短时间内有大量的流量，导致系统崩溃。由于每一个用户在请求时对应唯一的时间戳，所有的请求都有一个先后顺序，同样可以采用Redis Stream作为中间件，将请求加入到Redis Stream消息队列。将消息转存到消息队列间接提供给应用，而非直接发送给应用，可以防止大流量冲击导致的系统崩溃。当消息队列中的请求数量达到规定的最大值时，直接回复客户端抢购失败。三、原生Redis是否真的适用于以上场景？如上应用场景具有数据规模大、数据持续增长的特点，虽然原生Redis有良好的设计初衷，但是并不能解决实际问题。具体体现在：1）无法有效应对大规模数据：原生Redis是一个基于内存的数据库，单个节点存储容量有限，当扩展至TB级别的集群，将会出现管理困难，运维成本高等问题。2）集群扩容影响业务性能：原生Redis在进行集群扩容时，需要重新划分hash槽并进行数据迁移，必定会影响业务性能。3）数据可能会丢失：原生Redis虽然可以采用RDB和AOF的方式对数据进行持久化，但是并不会实时地将每一条命令写入到硬盘中，当出现掉电或集群崩溃的情况，必定会丢失一部分数据，对于类似智慧医疗场景，是难以忍受的。除此以外，必须考虑数据库系统的可用性、数据一致性、成本和备份恢复能力等情况：1）可用性： 原生Redis若采用一主一备的集群模式，当一对主备节点下线，集群部分数据将不可用。2）数据一致性：当主节点宕机，主备节点切换，数据存在没有完全同步的情况。3）成本：原生Redis是一种内存型数据库，当内存容量扩展至TB级别，成本将非常昂贵。4）备份恢复：需要人工连接数据库执行 SAVE或BGSAVE命令，不能支持定期自动备份，在恢复到新实例时需要手动拷贝备份数据。四、是否有更好的解决方案？在以上场景中，亟需一种能够存储和处理大规模Stream数据、鲁棒性强、且成本低廉的数据库系统。而GaussDB(for Redis)（下文简称高斯Redis）正是以上场景中一种很好的应用解决方案。高斯Redis是华为云数据库团队自主研发的兼容Redis协议的云原生数据库，该数据库突破原生Redis的内存限制，可轻松扩展至PB级存储，具有秒扩容、超可用、强一致和低成本等特点。五、总结Redis Stream可以广泛应用在即时通讯、智慧医疗、流量削峰等领域。在面对大规模的Stream数据时，原生Redis存在成本过高、容量太小、可用性差、数据不一致等问题，无法适用于海量消息队列的场景。与原生Redis相比，高斯Redis具有海量存储，低成本，可持久化等优点，可做为比原生Redis更理想的Stream队列承载方案。附：参考资料1. 《华为云GaussDB(for Redis)与自建开源Redis的成本对比》https://www.modb.pro/db/42739 2. 《一场由fork引发的超时，让我们重新探讨了Redis的抖动问题》https://bbs.huaweicloud.com/blogs/227525 3. 《当Redis遇见计算存储分离》https://developer.huaweicloud.com/hero/forum/thread-83188-1-1.html 4. 《GaussDB(for Redis)与原生Redis的性能对比》https://bbs.huaweicloud.com/blogs/236949 5. 《华为云PB级数据库GaussDB(for Redis)揭秘第一期：Redis与存算分离》https://bbs.huaweicloud.com/blogs/238584

说明本文以原生Redis5.0为例，分析其与GaussDB（for Redis）(下文简称高斯 Redis)的性能、成本比拼。对比成本比拼原生Redis的数据存放在内存中，高斯 Redis的数据存放在磁盘中，我们比较相同数据容量（192G）的成本开销。即使不考虑原生Redis的内存利用率打折，也可以得出，高斯 Redis的成本是原生Redis的1/3。压缩比拼采用Redis社区开源的压测工具memtier_benchmark写入相同的数据量，比较在两种数据库的空间占用：原生Redis实例高斯 Redis实例set命令压入数据31.23GB7.5GBhset命令压入数据53.62GB12.7GB即用户写入数据量一样的情况下，高斯 Redis的数据压缩比是原生Redis的4倍，因此用户在购买相同数据容量的前提下，高斯 Redis可以存4倍用户数据。性能比拼1. 环境准备Redis Labs推出的多线程压测工具memtier_benchmark，它能够产生各种各样的流量模型。因此采用memtier_benchmark对原生Redis实例和高斯 Redis实例进行性能评测。因为高斯 Redis最小实例的容量是48G，因此购买对标的原生Redis实例，为64G主从规格（实际可用内存“号称51.2G”）。2. 测试结果对比指标高斯 Redis原生Redisset(value=128kb)QPS13.06W11.23W平均时延(毫秒)11.6713.20P993822set(value=1024kb)QPS10.28W8.11W平均时延24.2016.63P998031getQPS39.72W16.76W平均时延3.813.20P99244setget(ratio=1:1,value=128kb)QPS19.93W13.11W平均时延7.423.81P99set:32,get:32set:5.8,get:5.9setget(ratio=1:1,value=1024kb)QPS17.86W9.96W平均时延7.2213.59P99set:30,get:30set:22,get:22hset(value=1024kb)QPS9.88W7.17W平均时延15.1120.91P997236hgetQPS41.35W15.96W平均时延3.539.39P993013hset hget(ratio=1:1,value=1024kb) QPS18.47W10.07W平均时延8.1314.87P99hset:54,hget53hset:24hget24总结1. 结论：与原生Redis实例相比，高斯 Redis在成本、可用容量、吞吐、压缩，都有非常巨大的优势，平均时延两者接近，p99时延有1倍差距。开源Redis高斯 Redis可用空间51.2GB192GB每小时￥27￥9压缩率1倍4倍吞吐比1倍1.5倍平均时延不相上下不相上下P991倍2倍2. 体会：在压测过程中，原生Redis由于容量小、数据无压缩，经常碰到OOM问题。推测下OOM原因，规格为64G的实例，其可用内存并没有宣称的51.2G那么大（怀疑只有50%）。另外，写压测时，流量太大很容易导致原生Redis主从堆积，进而触发RDB快照，导致OOM。而高斯 Redis抗写能力更稳定，且数据强一致存储，无主从堆积问题。可轻松应对业务扩张。

本案例使用python版本为python3.61、安装依赖注意依赖版本必须为如下版本先安装redis-py  2.10.6 版本 下载链接：   https://github.com/andymccurdy/redis-py/archive/2.10.6.tar.gz再安装 redis-py-cluster  1.3.5版本 下载链接:  https://files.pythonhosted.org/packages/f1/dd/4bb27bb3e3d03a01b0afd4a4ba13a4677b0f2d6552ff2841ac56591bfb29/redis-py-cluster-1.3.5.tar.gz下载后，上传到linux环境解压缩后，进入解压缩后目录，执行 python3 setup.py install2、测试验证脚本参考自 https://blog.csdn.net/shykevin/article/details/90509414如下代码连接的是  未开启安全模式的 FusionInsight 集群中的 Redis#!/usr/bin/env python3 from rediscluster import StrictRedisCluste class RedisCluster(object):  # 连接redis集群     def __init__(self, conn_list):         self.conn_list = conn_list  # 连接列表     def connect(self):         """         连接redis集群         :return: object         """         try:             redisconn = StrictRedisCluster(startup_nodes=self.conn_list)             return redisconn         except Exception as e:             print(e)             print("错误,连接redis 集群失败")             return False redis_basis_conn = [{'host': '10.244.230.10', 'port': 22400},                     {'host': '10.244.230.207', 'port': 22400},                     {'host': '10.244.230.58', 'port': 22400}] res = RedisCluster(redis_basis_conn).connect() if not res:     print("连接redis集群失败") else:     print("连接redis集群成功") redis_conn = RedisCluster(redis_basis_conn).connect()  # redis连接对象 redis_conn.set('name', 'admin')  # 插入一个值 print("name is: ", redis_conn.get('name'))  # 查询值

之前对华为云GaussDB(for Redis)做了一些功能性测试，本文想通过容量维度去对比测试下基于开源Redis在ECS上自建数据库，和使用华为云GaussDB(for Redis)的成本有何差别，供大家在做系统架构或者部署时参考（详细见文末对比表格）。首先说明一下自建Redis数据库需要在主机上自己搭建、部署、监控、运维，另外为了满足高可用要求，必须搭建主备或者集群。华为云GaussDB(for Redis)后台所有配置、监控等都对用户透明，只需通过IP、端口号、用户、密码连接数据库即可，支持在线扩容。另外，华为云GaussDB(for Redis)最少3个节点，后台存储也做了冗余。接下来我们对200GB容量的Redis数据库需求，来详细对比下二者的成本。针对GaussDB(for Redis)，直接购买200GB存储空间即可。基于开源Redis自建，根据官方最佳实践需要设置Redis最大使用内存为主机内存的45%：maxmemory=host_memory*45%，那么就需要购买444GB内存的ECS服务器，另外还需要购买一台同等配置的ECS用于搭建主备。PS：由于没有200GB规格的内存和存储空间，GaussDB(for Redis)购买192GB规则，ECS直接购买两台384GB规格。1、购买GaussDB(for Redis)选择4U16GB性能，存储空间192GB。如上费用为16.8每小时，一年费用为65,868。确认规则，直接购买。2、购买ECS购买192*2=384GB内存规则的ECS，（这里为了方便，直接购买单台384GB规则的ECS，用于测试）X86平台每小时24.1，两台也就是48.2。X86平台一年的费用为115,880，两台也就是231,760。3、确认规格GaussDB(for Redis)ECS：4、ECS搭建Redis直接使用yum安装，然后启动服务即可：[root@ecs-redis ~]# yum install redisLast metadata expiration check: 0:08:56 ago on Tue 22 Dec 2020 05:29:20 PM CST.Dependencies resolved.=========================================================================================================================================================================== Package                         Architecture                     Version                                                        Repository                           Size===========================================================================================================================================================================Installing: redis                           x86_64                           5.0.3-2.module_el8.2.0+318+3d7e67ea                            AppStream                           925 kEnabling module streams: redis                                                            5                                                                                                       Transaction Summary===========================================================================================================================================================================Install  1 PackageTotal download size: 925 kInstalled size: 3.2 MIs this ok [y/N]: yDownloading Packages:redis-5.0.3-2.module_el8.2.0+318+3d7e67ea.x86_64.rpm                                                                                       3.6 MB/s | 925 kB     00:00    ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------Total                                                                                                                                      1.3 MB/s | 925 kB     00:00     warning: /var/cache/dnf/AppStream-a520ed22b0a8a736/packages/redis-5.0.3-2.module_el8.2.0+318+3d7e67ea.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 8483c65d: NOKEYCentOS-8 - AppStream                                                                                                                       1.6 MB/s | 1.6 kB     00:00    Importing GPG key 0x8483C65D: Userid     : "CentOS (CentOS Official Signing Key) <security@centos.org>" Fingerprint: 99DB 70FA E1D7 CE22 7FB6 4882 05B5 55B3 8483 C65D From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficialIs this ok [y/N]: yKey imported successfullyRunning transaction checkTransaction check succeeded.Running transaction testTransaction test succeeded.Running transaction  Preparing        :                                                                                                                                                   1/1  Running scriptlet: redis-5.0.3-2.module_el8.2.0+318+3d7e67ea.x86_64                                                                                                  1/1  Installing       : redis-5.0.3-2.module_el8.2.0+318+3d7e67ea.x86_64                                                                                                  1/1  Running scriptlet: redis-5.0.3-2.module_el8.2.0+318+3d7e67ea.x86_64                                                                                                  1/1  Verifying        : redis-5.0.3-2.module_el8.2.0+318+3d7e67ea.x86_64                                                                                                  1/1 Installed:  redis-5.0.3-2.module_el8.2.0+318+3d7e67ea.x86_64                                                                                                                         Complete![root@ecs-redis ~]# [root@ecs-redis ~]# service redis startRedirecting to /bin/systemctl start redis.service[root@ecs-redis ~]# [root@ecs-redis ~]# [root@ecs-redis ~]# [root@ecs-redis ~]# [root@ecs-redis ~]# redis-cli127.0.0.1:6379> 127.0.0.1:6379> 5、测试写入200GB数据测试写入200GB左右的数据到Redis中：本机ECS：[root@ecs-redis ~]# redis-benchmark  -t set -d 1000000 -n 196000 -r 10000000000====== SET ======  196000 requests completed in 188.03 seconds  50 parallel clients  1000000 bytes payload  keep alive: 10.00% <= 1 milliseconds0.00% <= 2 milliseconds0.00% <= 3 milliseconds0.00% <= 4 milliseconds...100.00% <= 1171 milliseconds1042.38 requests per second[root@ecs-redis ~]# GaussDB(for Redis):[root@ecs-ae88 ~]# redis-benchmark -h 192.168.0.93 -p 8635 -a 'Redis2020!' -t set -d 1000000 -n 196000 -r 10000000000====== SET ======  196000 requests completed in 725.30 seconds  50 parallel clients  1000000 bytes payload  keep alive: 10.00% <= 5 milliseconds0.11% <= 6 milliseconds...100.00% <= 3303 milliseconds270.23 requests per second6、200GB数据结果本机ECS：dbsize为19万，使用内存接近200GB。[root@ecs-redis ~]# free -m              total        used        free      shared  buff/cache   availableMem:         386715      151995      233548           8        1171      232569Swap:             0           0           0[root@ecs-redis ~]# free -m              total        used        free      shared  buff/cache   availableMem:         386715      153388      232141           8        1184      231176Swap:             0           0           0[root@ecs-redis ~]# free -m              total        used        free      shared  buff/cache   availableMem:         386715      154101      231422           8        1191      230463Swap:             0           0           0[root@ecs-redis ~]# free -m              total        used        free      shared  buff/cache   availableMem:         386715      154759      230757           8        1199      229805Swap:             0           0           0[root@ecs-redis ~]# free -m              total        used        free      shared  buff/cache   availableMem:         386715      155376      230134           8        1205      229188Swap:             0           0           0[root@ecs-redis ~]# free -m              total        used        free      shared  buff/cache   availableMem:         386715      199974      185070           8        1670      184585Swap:             0           0           0[root@ecs-redis ~]# free -m              total        used        free      shared  buff/cache   availableMem:         386715      199974      185062           8        1678      184584Swap:             0           0           0[root@ecs-redis ~]# redis-cli dbsize(integer) 195980[root@ecs-redis ~]# redis-cli dbsize(integer) 195980GaussDB(for Redis):查看存储空间仅使用了20GB左右，这是由于GaussDB(for Redis)后台使用了压缩算法，所以这里看到的测试数据被压缩了10倍。7、测试写入400GB左右的数据：本机ECS：测试到一半，主机直接崩溃，执行任何命令都报错Cannot allocate memory。[root@ecs-redis ~]# redis-benchmark  -t set -d 2000000 -n 196000 -r 10000000000^CT: 321.36[root@ecs-redis ~]# redis-cli-bash: fork: Cannot allocate memory[root@ecs-redis ~]# redis-cli FLUSHDB-bash: fork: Cannot allocate memory[root@ecs-redis ~]# redis-cli FLUSHDB-bash: fork: Cannot allocate memory[root@ecs-redis ~]# ps -ef|grep redis-bash: fork: Cannot allocate memory[root@ecs-redis ~]# ps -ef-bash: fork: Cannot allocate memory[root@ecs-redis ~]# ps -ef-bash: fork: Cannot allocate memory[root@ecs-redis ~]# restart-bash: fork: Cannot allocate memory[root@ecs-redis ~]# --内存变化：[root@ecs-redis ~]# free -g              total        used        free      shared  buff/cache   availableMem:            377          15         361           0           0         360Swap:             0           0           0[root@ecs-redis ~]# free -g              total        used        free      shared  buff/cache   availableMem:            377          17         359           0           0         358Swap:             0           0           0...[root@ecs-redis ~]# free -g              total        used        free      shared  buff/cache   availableMem:            377         345          28           0           2          29Swap:             0           0           0[root@ecs-redis ~]# free -g              total        used        free      shared  buff/cache   availableMem:            377         346          28           0           2          29Swap:             0           0           0[root@ecs-redis ~]# free -g^[[A^[[B^[[A-bash: fork: Cannot allocate memoryGaussDB(for Redis):[root@ecs-ae88 ~]# redis-benchmark -h 192.168.0.93 -p 8635 -a 'Redis2020!' -t set -d 2000000 -n 196000 -r 10000000000====== SET ======  196000 requests completed in 1330.57 seconds  50 parallel clients  2000000 bytes payload  keep alive: 10.00% <= 7 milliseconds0.00% <= 8 milliseconds0.00% <= 10 milliseconds0.00% <= 11 milliseconds...100.00% <= 20100 milliseconds100.00% <= 20108 milliseconds147.31 requests per second正常写入了400GB左右的数据，查看控制台存储空间使用26.5G，压缩比例更高了，当然这也与测试的数据有很大关系。8、测试写入2T左右的数据测试写入2T左右的数据到GaussDB(for Redis)，验证压缩比例：[root@ecs-ae88 ~]# redis-benchmark -h 192.168.0.93 -p 8635 -a 'Redis2020!' -t set -d 2000000 -n 1000000 -r 100000000000====== SET ======  1000000 requests completed in 10124.11 seconds  50 parallel clients  2000000 bytes payload  keep alive: 10.00% <= 5 milliseconds0.00% <= 7 milliseconds...100.00% <= 20107 milliseconds100.00% <= 20108 milliseconds98.77 requests per second查看后台存储空间使用了126.7GB，压缩比也在1:10以上。这里换算成自建开源Redis，需要2T * 2 *2=8T的可用内存，并且此时也只有搭建集群才能满足需求，对应的实际成本会高很多。总结在容量充足的情况下，我们验证了自建开源Redis和华为GaussDB(for Redis)数据都能正常写入，且数据库大小相同。两者的详细价格如下：ECS+开源RedisGaussDB(for Redis)可用空间384GB*45%192GB压缩比无压缩1:10每小时¥ 48.2¥ 16.8包年¥ 231,760¥ 65,868从上面可以看出，在不考虑压缩的情况下，基于开源Redis自建的费用差不多是购买华为云GaussDB(for Redis)的四倍。另外，从测试数据来看，华为云GaussDB(for Redis)的磁盘空间压缩比在1:10以上，也就是可用空间是至少是相同容量规则自建Redis的十倍。核算下来，华为云GaussDB(for Redis)以1/4的价格拥有10倍以上的可用空间，整体成本相当于是开源Redis自建数据库的1/40，这里还不包括自建Redis数据库需要额外的搭建、运维、监控、升级扩容等各项成本。如果云上项目或者即将上云项目中有需要用到Redis，建议大家可以考虑选择华为云GaussDB(for Redis)。赶紧戳这里，了解更多详情吧~~

背景介绍华为云数据库GaussDB(for Redis) 是一款基于计算存储分离架构，兼容Redis生态的云原生NoSQL数据库；它依靠共享存储池实现了强一致，支持持久化落盘存储，保证数据的安全可靠。其核心特点是：存算分离、强一致、低成本、超大容量。GaussDB(for Redis)服务团队在支撑某客户业务上云的过程中，发现一次由fork引发的时延抖动问题，本着对客户负责任的态度，我们详细探究了fork这个系统调用的性能影响，并且在最新的GaussDB(for Redis)版本已解决了这个抖动问题，清零了内部的fork使用，与原生Redis相比，彻底解决了fork的性能隐患。问题焦点1)     华为云GaussDB(for Redis) 服务在某客户上云线调测过程中发现，系统上量后规律性的出现每5分钟1次的时延抖动问题。2)     华为云GaussDB(for Redis)团队经过攻关，最终确认抖动原因是fork导致并解决了这个问题。而fork是开源Redis的一个重要依赖，希望通过本文的分享，能够帮助大家在使用开源Redis的时候，充分认识fork的影响，从而选择更优的方案。问题现象某客户业务接入GaussDB(for Redis)压测发现，每5分钟系统出现一次规律性的时延抖动：1)     正常情况消息时延在1-3ms，抖动时刻时延达到300ms左右。2)     通常是压测一段时间后开始出现抖动；抖动一旦出现后就非常规律的保持在每5分钟1次；每次抖动的持续时长在10ms以内。下图是从系统慢日志中捕获到的发生抖动的消息样例（对敏感信息进行了遮掩）：问题分析        1.     排查抖动源：1)     由于故障的时间分布非常规律，首先排除定时任务的影响，主要包括：l  agent：和管控对接的周期性统计信息上报任务l  内核：执行引擎（Redis协议解析）和存储引擎（rocksdb）的周期性操作（包括rocskdb统计，wal清理等）屏蔽上述2类定时任务后，抖动依然存在。2)     排除法未果后，决定回到正向定位的路上来。通过对数据访问路径增加分段耗时统计，最终发现抖动时刻内存操作（包括allocate、memcpy等）的耗时显著变长；基本上长出来的时延，都是阻塞在了内存操作上。                                              （截图为相关日志，单位是微秒）3)     既然定位到是系统级操作的抖动，那么下一步的思路就是捕获抖动时刻系统是否有异常。我们采取的方法是，通过脚本定时抓取top信息，分析系统变化。运气比较好，脚本部署后一下就抓到了一个关键信息：每次在抖动的时刻，系统中会出现一个frm-timer进程；该进程为GaussDB(for Redis)进程的子进程，且为瞬时进程，持续1-2s后退出。4)     为了确认该进程的影响，我们又抓取了perf信息，发现在该进程出现时刻，Kmalloc， memset_sse，memcopy_sse等内核系统调用增多。从上述信息推断，frm-timer进程应该是被fork出来的，抖动源基本可锁定在fork frm-timer这个动作上。2.     确定引发抖动的代码：1)     分析frm-timer的来历是下一步的关键。因为这个标识符不在我们的代码中，所以就需要拉通给我们提供类库的兄弟部门联合分析了。经过大家联合排查，确认frm-timer是日志库liblog中的一个定时器处理线程。如果这个线程fork了一个匿名的子进程，就会复用父进程的线程名，表现为Redis进程创建出1个名为frm-timer的子进程的现象。2)     由于frm-timer负责处理liblog中所有模块的定时器任务，究竟是哪个模块触发了上述fork？这里我们采取了一个比较巧妙的方法，我们在定时器处理逻辑中增加了一段代码：如果处理耗时超过30ms，则调用std:: abort()退出，以生成core栈。3)     通过分析core栈，并结合代码排查，最终确认引发抖动的代码如下：上述代码是用来周期性归档日志的，它每5分钟会执行1次 system系统调用来运行相关脚本，完成归档日志的操作。而Linux system系统调用的源码如下，实际上是一个先fork子进程，再调用execl的过程。4)     分析至此，我们还需要回答最后一个问题：究竟是fork导致的抖动，还是脚本内容导致的抖动？为此，我们设计了一组测试用例：l  用例1：将脚本内容改为最简单的echo操作l  用例2：在Redis进程里模拟1个类似frm-timer的线程，通过命令触发该线程执行fork操作l  用例3：在Redis进程里模拟1个类似frm-timer的线程，通过命令触发该线程执行先fork，再excel的操作l  用例4：在Redis进程里模拟1个类似frm-timer的线程，通过命令触发该线程执行system的操作l  用例5：在Redis进程里模拟1个类似frm-timer的线程，通过命令触发该线程执行先vfork，再excel的操作最终的验证结果：l  用例1：有抖动。l  用例2：有抖动。l  用例3：有抖动。l  用例4：有抖动。l  用例5：无抖动。用例1结果表明抖动和脚本内容无关；用例2、3、4的结果表明调用system引发抖动的根因是因为其中执行了fork操作；用例5的结果进一步佐证了抖动的根因就是因为fork操作。最终的故障原因示意图如下：3.     进一步探究fork的影响：1)     众所周知，fork是Linux（严格说是POSIX接口）创建子进程的系统调用，历史上看，主流观点大多对其赞誉有加；但近年间随着技术演进，也陆续出现了反对的声音：有人认为fork是上个时代遗留的产物，在现代操作系统中已经过时，有很多害处。激进的观点甚至认为它应该被彻底弃用。（参见附录1,2）2)     fork当前被诟病的主要问题之一是它的性能。大家对fork通常的理解是其采用copy-on-wirte写时复制策略，因此对其的性能影响不甚敏感。但实际上，虽然fork时可共享的数据内容不需要复制，但其相关的内核数据结构（包括页目录、页表、vm_area_struc等）的复制开销也是不容忽视的。附录1、2中的文章对fork开销有详细介绍，我们这回遇到的问题也是一个鲜活的案例：对于Redis这样的时延敏感型应用，1次fork就可能导致消息时延出现100倍的抖动，这对于应用来说无疑是不可接受的。4.     原生Redis的fork问题：4.1 原生Redis同样被fork问题困扰（参见附录3，4，5），具体包括如下场景： 1）数据备份                                                                            备份时需要生成RDB文件，因此Redis需要触发一次fork。2）主从同步全量复制场景（包括初次复制或其他堆积严重的情况），主节点需要产生RDB文件来加速同步，同样需要触发fork。3）AOF重写       当AOF文件较大，需要合并重写时，也会产生一次fork。4.2 上述fork问题对原生Redis的影响如下：1）业务抖动原生Redis采用单线程架构，如果在电商大促、热点事件等业务高峰时发生上述fork，会导致Redis阻塞，进而对业务造成雪崩的影响。2）内存利用率只有50%Fork时子进程需要拷贝父进程的内存空间，虽然是COW，但也要预留足够空间以防不测，因此内存利用率只有50%，也使得成本高了一倍。3）容量规模影响为减小fork的影响，生产环境上原生Redis单个进程的最大内存量，通常控制在5G以内，导致原生Redis实例的容量大大受限，无法支撑海量数据。解决方法1.      修改日志库liblog中的周期性归档逻辑，不再fork子进程。2.      系统排查并整改GaussDB(for Redis)代码（包括使用的类库代码）中的fork调用。3.      最终排查结果，实际只有本次的这个问题点涉及fork。当前修改后即可确保GaussDB(for Redis)的时延保持稳定，不再受fork性能影响。注：GaussDB(for Redis)由华为云基于存算分离架构自主开发，因此不存在原生Redis的fork调用的场景。总结本文通过分析GaussDB(for Redis)的一次由fork引发的时延抖动问题，探究了fork这个系统调用的性能影响。最新的GaussDB(for Redis)版本已解决了这个抖动问题，并清零了内部的fork使用，与原生Redis相比，彻底解决了fork的性能隐患。希望通过这个问题的分析，能够带给大家一些启发，方便大家更好的选型。   附： 1.[是时候淘汰对操作系统的 fork() 调用了] https://www.infoq.cn/article/BYGiWI-fxHTNvSohEUNW2.[Linux fork那些隐藏的开销] https://www.mdeditor.tw/pl/29L03.[Redis官方文档] https://redis.io/topics/latency4.[Redis的一些坑] https://www.jianshu.com/p/03df6fd516eb5.[Redis 常见问题之-fork操作]https://blog.csdn.net/longgeqiaojie304/article/details/894072146.[GaussDB(for Redis)官网链接]https://www.huaweicloud.com/product/gaussdbforredis.html

2020-12-21：redis中，rpop和brpop的区别？#福大大架构师每日一题#

1、增加节点，新节点密码不知道是什么，必须重置密码才能登陆2、删除节点，只删了前台的Proxy，而后台的server并没有删除。相关测试文章：《华为云GaussDB(for Redis)数据库——在线加减节点及扩容》https://www.modb.pro/db/42243

【开发者最佳实践挑战】第3关任务：使用Redis实现排行榜功能在网页和APP中常常需要用到榜单的功能，对某个key-value的列表进行降序显示。当操作和查询并发大的时候，使用传统数据库就会遇到性能瓶颈，造成较大的时延。使用分布式缓存服务（DCS）的Redis版本，可以实现一个商品热销排行榜的功能。它的优势在于：  数据保存在缓存中，读写速度非常快。  提供字符串（String）、链表（List）、集合（Set）、哈希（Hash）等多种数据结构类型的存储。 （1）领取实践资源：1元ECS+Redis资源。点击这里领取资源或复制打开链接购买：http://suo.im/5FyHMG  （华南广州）（2）最佳实践指南：点击查看实践指南>> 注：登录ECS可以有多种方式，Windows推荐使用MSTSC方式远程链接桌面>>（3）视频操作演示：点击查看实践视频演示>>昨天晚上下班之前，买了资源，当时也没细看（惨痛的实践教训证明，好多坑都是被自己没细看挖出来的~），今天上班来继续购买下面的DCS资源，还顺手就买到了北京4区域，买完了才发现，ECS在广州，，删掉重新在广州区域买DCS，才发现昨天买的包里已经有DCS了。登录到ECS中，按照手册安装eclipse,网页访问不了。首先想到是防火墙的问题，因为已经远程上来了么，网络肯定是通的了。修改防火墙后，果然网络通了。下载eclipse的安装包，很慢，预计要30分钟+，回头看看能不能加点带宽，1M的是小了点，2M就开始收费了，算了，我一边做实验一边记录，也不是很急哈！到饭点了，先写到这。。。。。身体最重要~eclipse安装一路畅通，卡在redis客户端的引用上面了。参照了手册，视频，百度，各种查询搜索，还是不行，最后还是在module-info那里，添加了包的声明搞定了。之后就是网络排障了！报redis后台的timeout错误，这个错误就很模糊，到底是通了没连接呢，还是压根就没通呢？网络故障，咱是强项啊~就是做这个的查吧，cmd先ping一下，不通，有可能这个地址没有配置，也有可能是不让ping，换个地址继续测试，用99的地址试一下，eclipse运行后提示不能连接到备用端有门！基本上成功90%了，。这证明已经成功探测到redis后台了，只是地址不对！继续用242的主用侧地址测试，成功！用对外的业务地址145测试，也是通的！最后证明还是地址写错了，145写成了245，改过来就通了。这个实验很简单，只是简单的使用redis服务，发现可以分析大key了，又可以捎带手赚码豆了！开心！

 摘要：由于redis是基于内存的数据库，稳定性并不是很高，尤其是standalone模式下的redis。于是工作中在使用Spark-Redis时也会碰到很多问题，尤其是执行海量数据插入与查询的场景中。海量数据查询Redis是基于内存读取的数据库，相比其它的数据库，Redis的读取速度会更快。但是当我们要查询上千万条的海量数据时，即使是Redis也需要花费较长时间。这时候如果我们想要终止select作业的执行，我们希望的是所有的running task立即killed。Spark是有作业调度机制的。SparkContext是Spark的入口，相当于应用程序的main函数。SparkContext中的cancelJobGroup函数可以取消正在运行的job。/**  * Cancel active jobs for the specified group. See `org.apache.spark.SparkContext.setJobGroup`  * for more information.  */ def cancelJobGroup(groupId: String) {   assertNotStopped()   dagScheduler.cancelJobGroup(groupId) }按理说取消job之后，job下的所有task应该也终止。而且当我们取消select作业时，executor会throw TaskKilledException，而这个时候负责task作业的TaskContext在捕获到该异常之后，会执行killTaskIfInterrupted。 // If this task has been killed before we deserialized it, let's quit now. Otherwise, // continue executing the task. val killReason = reasonIfKilled if (killReason.isDefined) {   // Throw an exception rather than returning, because returning within a try{} block   // causes a NonLocalReturnControl exception to be thrown. The NonLocalReturnControl   // exception will be caught by the catch block, leading to an incorrect ExceptionFailure   // for the task.   throw new TaskKilledException(killReason.get) }/** * If the task is interrupted, throws TaskKilledException with the reason for the interrupt. */ private[spark] def killTaskIfInterrupted(): Unit但是Spark-Redis中还是会出现终止作业但是task仍然running。因为task的计算逻辑最终是在RedisRDD中实现的，RedisRDD的compute会从Jedis中取获取keys。所以说要解决这个问题，应该在RedisRDD中取消正在running的task。这里有两种方法：方法一：参考Spark的JDBCRDD，定义close()，结合InterruptibleIterator。def close() {   if (closed) return   try {     if (null != rs) {       rs.close()     }   } catch {     case e: Exception => logWarning("Exception closing resultset", e)   }   try {     if (null != stmt) {       stmt.close()     }   } catch {     case e: Exception => logWarning("Exception closing statement", e)   }   try {     if (null != conn) {       if (!conn.isClosed && !conn.getAutoCommit) {         try {           conn.commit()         } catch {           case NonFatal(e) => logWarning("Exception committing transaction", e)         }       }       conn.close()     }     logInfo("closed connection")   } catch {     case e: Exception => logWarning("Exception closing connection", e)   }   closed = true }  context.addTaskCompletionListener{ context => close() } CompletionIterator[InternalRow, Iterator[InternalRow]](   new InterruptibleIterator(context, rowsIterator), close())方法二：异步线程执行compute，主线程中判断task isInterruptedtry{   val thread = new Thread() {     override def run(): Unit = {       try {          keys = doCall       } catch {         case e =>           logWarning(s"execute http require failed.")       }       isRequestFinished = true     }   }    // control the http request for quite if user interrupt the job   thread.start()   while (!context.isInterrupted() && !isRequestFinished) {     Thread.sleep(GetKeysWaitInterval)   }   if (context.isInterrupted() && !isRequestFinished) {     logInfo(s"try to kill task ${context.getKillReason()}")     context.killTaskIfInterrupted()   }   thread.join()   CompletionIterator[T, Iterator[T]](     new InterruptibleIterator(context, keys), close)我们可以异步线程来执行compute，然后在另外的线程中判断是否task isInterrupted，如果是的话就执行TaskContext的killTaskIfInterrupted。防止killTaskIfInterrupted无法杀掉task，再结合InterruptibleIterator：一种迭代器，以提供任务终止功能。通过检查[TaskContext]中的中断标志来工作。海量数据插入我们都已经redis的数据是保存在内存中的。当然Redis也支持持久化，可以将数据备份到硬盘中。当插入海量数据时，如果Redis的内存不够的话，很显然会丢失部分数据。这里让使用者困惑的点在于： 当Redis已使用内存大于最大可用内存时，Redis会报错：command not allowed when used memory > ‘maxmemory’。但是当insert job的数据大于Redis的可用内存时，部分数据丢失了，并且还没有任何报错。因为不管是Jedis客户端还是Redis服务器，当插入数据时内存不够，不会插入成功，但也不会返回任何response。所以目前能想到的解决办法就是当insert数据丢失时，扩大Redis内存。总结Spark-Redis是一个应用还不是很广泛的开源项目，不像Spark JDBC那样已经商业化。所以Spark-Redis还是存在很多问题。相信随着commiter的努力，Spark-Redis也会越来越强大。

GaussDB for Redis提供Info命令查询系统内部的一些统计信息，使用方法为：通过redis-cli登录proxy，执行如下命令即可。info Latency cmd: 打印某个cmd的执行信息，包括执行次数，时间。支持的cmd参数有：“all”，“get”，“lindex”，“lpush”，“sadd”，“set”，“spop”，“xadd”，“xread”，“zadd”，“zrem”info ServerLatency serverName [cmd]: 打印特定server的命令统计信息info SystemResource： 打印系统级参数，内存使用量，cpu使用等info stats: 打印服务的状态，包括接受的连接数，总请求数，流量等info servers: 打印各个server（shard）的信息，包括name，请求数等info LatencyMonitor: 执行监控命令的执行信息info route: 打印路由信息info proxy | server: 打印proxy参数信息，包括version，name等info [all]: 打印上述3，4，5，6，8的信息

ARM架构系统源码编译安装Rdis一、环境信息：系统版本：Centos7.6二、编译和安装Redis步骤如下：执行如下命令，获取Redis源码。      wget http://download.redis.io/releases/redis-4.0.9.tar.gz执行如下命令，解压包。      tar -zxvf redis-4.0.9.tar.gz执行如下命令，进入deps目录。      cd redis/deps执行如下命令，编译Redis依赖库。       make -j4 hiredis lua jemalloc linenoise依次执行如下命令，编译Redis。      cd ..      make -j4      make install三、配置和运行Redis执行如下命令，建立redis配置文件。       cp redis.conf /usr/local/etc/执行如下命令，配置redis为后台启动,将daemonize no 改成daemonize yes。      vim /usr/local/etc/redis.conf 设置Redis开机启动。    a.         执行如下命令，将Redis启动脚本放置/etc/init.d/目录下，并命名为redis。    cp redis/utils/redis_init_script /etc/init.d/redis    b.         执行如下命令，修改脚本内容。    vim /etc/init.d/redis    修改：CONF=/usr/local/etc/redis.conf设置服务开启启动。       chkconfig redis on执行如下命令，启动redis-server。      service redis start