• [交流分享] 关于幂等性的学习笔记
    最基础的概念,什么是幂等性?幂等性:提交多次的情况下,结果都一样。比如数据库查询,可称为天然幂等性,即查询多次结果都一样,无需人为去做幂等性操作。但是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、业务层面加分布式锁将获取、对比、删除作为一个原子性的操作加锁,处理完成后释放锁,确保串行操作。三、约束数据库唯一约束:通过主键、唯一索引,确保无法重复新增同一笔数据,这就能确保幂等性
  • [交流分享] 关于幂等性的学习笔记
    最基础的概念,什么是幂等性?幂等性:提交多次的情况下,结果都一样。比如数据库查询,可称为天然幂等性,即查询多次结果都一样,无需人为去做幂等性操作。但是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、业务层面加分布式锁将获取、对比、删除作为一个原子性的操作加锁,处理完成后释放锁,确保串行操作。三、约束数据库唯一约束:通过主键、唯一索引,确保无法重复新增同一笔数据,这就能确保幂等性
  • [技术干货] 关于幂等性的学习笔记
    最基础的概念,什么是幂等性?幂等性:提交多次的情况下,结果都一样。比如数据库查询,可称为天然幂等性,即查询多次结果都一样,无需人为去做幂等性操作。但是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、业务层面加分布式锁将获取、对比、删除作为一个原子性的操作加锁,处理完成后释放锁,确保串行操作。三、约束数据库唯一约束:通过主键、唯一索引,确保无法重复新增同一笔数据,这就能确保幂等性
  • [交流吐槽] 关于幂等性的学习笔记
    最基础的概念,什么是幂等性?幂等性:提交多次的情况下,结果都一样。比如数据库查询,可称为天然幂等性,即查询多次结果都一样,无需人为去做幂等性操作。但是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、业务层面加分布式锁将获取、对比、删除作为一个原子性的操作加锁,处理完成后释放锁,确保串行操作。三、约束数据库唯一约束:通过主键、唯一索引,确保无法重复新增同一笔数据,这就能确保幂等性
  • [服务构建器] 【华为云Stack ManageOne 服务构建器】通过服务构建器申请安装一个Redis集群服务
    1 背景信息 ------------ 本文以服务构建器部署Redis为例,演示如何通过服务构建器自动化部署Redis集群服务。 ------------ 2 业务分析 ------------ 创建两个弹性云服务器,并在弹性云服务器中安装Redis键值对存储数据库集群。该集群拥有六个节点,三个主节点安装在主服务器,三个从节点安装在从服务器。Redis是一个开源(BSD许可),内存数据结构存储,可用作数据库,缓存和消息代理。 ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202112/28/153439rperv8vm2qimfewf.png) ------------ ## 3 准备 ### 3.1 镜像 CentOS 7.9 (x86_64)已预置gcc环境和expect环境,且成功安装Cloud-Init。 ### 3.2 软件包 请提前准备以下软件包。 | 软件包名称 | 说明 | |----|----| | redis-6.2.6.tar.gz | Redis的安装文件。 官网下载路径参考:https://download.redis.io/releases/redis-6.2.6.tar.gz ------------ ## 4 规划配置 ### 4.1 资源规划 网络规划如下: | 资源 | 具体操作 | |----|----| | 虚拟私有云 | 在虚拟私有云Console提前申请VPC和子网。 | ------------ 需要一台弹性云服务器安装Nginx,具体配置如下: | 资源 |推荐配置 | |----|----| | 内存 | 4G | | vCPUs | 2 | | 系统盘大小 | 20G | ------------ ### 4.2 模板设计 本次模板设计使用服务构建器图形化设计器,详细说明见下文。 - 模板设计 ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202112/28/153914vmeguldotbtzrl22.png) - 模板资源节点说明 | 节点名称 | 资源类型 | 作用 | |----|----|----| |CloudServer3uftf|HCS::ECS::CloudServer|Redis主节点服务器| |CloudServerazu|HCS::ECS::CloudServer|Redis从节点服务器| |SoftwareDeploymentm9jv|HCS::AutoOps::SoftwareDeployment|主节点Agent与脚本配置绑定| |SoftwareDeployment33d4b|HCS::AutoOps::SoftwareDeployment|从节点Agent与脚本配置绑定| |Agent5myc|HCS::AutoOps::Agent|主节点Agent| |Agent4wn65|HCS::AutoOps::Agent|从节点Agent| |Volume1j0p5|HCS::EVS::Volume|Redis主节点挂载的数据盘| |Volume2jous|HCS::EVS::Volume|Redis从节点挂载的数据盘| |SoftwareConfig1dip8|OS::Heat::SoftwareConfig|安装Redis主节点的脚本配置文件| |SoftwareConfig2c8fm|OS::Heat::SoftwareConfig|安装Redis从节点的脚本配置文件| ------------ - 模板参数节点说明 ------------ 服务器基本配置 | 参数Label | 参数名称 | 参数说明 | |----|----|----| | 可用分区 | availability_zone_ba4man | Redis服务器所在的可用分区 | | 镜像| image_utdqif | Redis服务器的系统镜像,需要指定已创建镜像的ID或名称。 | | 规格| flavor_3psdq6 | Redis服务器的系统规格的ID | | 系统盘大小| size_ge1xyv | Redis服务器的系统盘大小,以GB为单位。该值应大于或等于镜像的大小 | | 磁盘类型|volume_type_bijuat | Redis服务器数据盘对应的磁盘类型,需要与系统所提供的磁盘类型相匹配。磁盘类型枚举值:SATA:普通IO磁盘类型。SAS:高IO磁盘类型。SSD:超高IO磁盘类型 | | 主Redis服务器名称 |name_1dwipj | Redis主节点服务器名称 | | 从Redis服务器名称 |name_5gtfm6 | Redis从节点服务器名称 | ------------ 服务器网络配置 | 参数Label | 参数名称 | 参数说明 | |----|----|----| | 子网 | subnet_id_gea3wc | Redis服务器的网卡所属网络 | | 主节点1端口 | master_ip_port1_959nxa | 主节点1接受连接的指定端口 | | 主节点2端口 | master_ip_port2_6l6ip6 | 主节点2接受连接的指定端口 | | 主节点3端口 | master_ip_port3_nnhbqz | 主节点3接受连接的指定端口 | | 从节点1端口 | slave_ip_port1_a1ayi7 | 从节点1接受连接的指定端口 | | 从节点2端口 | slave_ip_port2_esajmx | 从节点2接受连接的指定端口 | | 从节点3端口 | slave_ip_port3_7mxshi | 从节点3接受连接的指定端口 | ------------ Agent配置 | 参数Label | 参数名称 | 参数说明 | |----|----|----| |Agent管理员密码|admin_pass_e2c513|服务器管理员的密码| |Agent管理员用户名|admin_user_po2bfq|服务器管理员的用户名| |脚本类型|type_4hsqsz|脚本文件的类型,仅支持python,shell| ------------ 数据盘配置 | 参数Label | 参数名称 | 参数说明 | |----|----|----| |数据盘类型|volume_type_r9n8yw|云硬盘类型的名称或者ID| |数据盘容量|size_1gr9a3|云硬盘的大小,单位GB| ------------ 软件配置 | 参数Label | 参数名称 | 参数说明 | |----|----|----| |Redis下载地址|redis_source_url_51dv0|Redis安装包的下载地址。(例如:http://[软件源云服务器私有IP]/packages/ redis-6.2.6.tar.gz)| |Redis安装路径|redis_install_path_ovhzzi|Redis安装路径(例如:/opt)| |Redis日志路径|redis_log_path_j3rr9b|Redis日志路径(例如:/opt/log)| |Redis数据路径|redis_data_path_8z9zt1|Redis数据路径(例如:/redis/data)| ------------ - 输出信息节点说明 | 输出信息 | 描述 | |----|----| |主节点IP地址|Redis主服务器的私有IP地址| |从节点IP地址|Redis从服务器的私有IP地址| ------------ ### 4.3 脚本设计 - Redis安装脚本 请参考附件中主Redis.sh和从Redis.sh脚本 ------------ - Redis主服务器安装脚本输入参数说明 | 参数Label | 参数名称 | 参数说明 | |----|----|----| |Redis下载地址|redis_source_url|Redis安装包的下载地址。(例如:http://[软件源云服务器私有IP]/packages/ redis-6.2.6.tar.gz)| |Redis安装路径|redis_install_path|Redis安装路径(例如:/opt)| |Redis日志路径|redis_log_path|Redis日志路径。(例如:/opt/log)| |Redis数据路径|redis_data_path|Redis数据路径。(例如:/redis/data)| |Redis主节点挂载的数据盘|master_data_disk|Redis主节点挂载的数据盘(例如:/dev/vdb)| |从节点IP地址|slave_ip_addr|Redis集群从节点服务器的IP地址| |主节点1端口|master_ip_port1|主节点1接受连接的指定端口(例如:7000)| |主节点2端口|master_ip_port2|主节点2接受连接的指定端口(例如:7001)| |主节点3端口|master_ip_port3|主节点3接受连接的指定端口(例如:7002)| |从节点1端口|slave_ip_port1|从节点1接受连接的指定端口(例如:7003)| |从节点2端口|slave_ip_port2|从节点2接受连接的指定端口(例如:7004)| |从节点3端口|slave_ip_port3|从节点3接受连接的指定端口(例如:7005)| ------------ - Redis从服务器安装脚本输入参数说明 | 参数Label | 参数名称 | 参数说明 | |----|----|----| |Redis下载地址|redis_source_url|Redis安装包的下载地址。(例如:http://[软件源云服务器私有IP]/packages/ redis-5.0.3.tar.gz)| |Redis安装路径|redis_install_path|Redis安装路径(例如:/home/redis)| |Redis日志路径|redis_log_path|Redis日志路径。(例如:/opt/log)| |Redis数据路径|redis_data_path|Redis数据路径。(例如:/redis/data)| |Redis从节点挂载的数据盘|slace_data_disk|Redis从节点挂载的数据盘(例如:/dev/vdb)| |从节点1端口|slave_ip_port1|Redis集群从节点1端口(例如:7003)| |从节点2端口|slave_ip_port2|Redis集群从节点2端口(例如:7004)| |从节点3端口|slave_ip_port3|Redis集群从节点3端口(例如:7005)| ------------ ## 5 申请服务 按照前期规划填写用户参数。 ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202112/28/160449hgq1sbe7pqjwsmok.png) 镜像应选择:CentOS-7-9-x86_64的操作系统,系统盘大小应大于镜像大小。 ------------ ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202112/28/160529auludtp3m5nsgie0.png) 网卡应该和软件仓库在同一VPC下。弹性IP的外部网络要选EIP类型的外部网络。 ------------ ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202112/28/160555tzxgs7m8m3mz1itb.png) Agent管理员的账号和密码为所选镜像的账号密码。 ------------ ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202112/28/1606571sw3omqdczqqz98y.png) ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202112/28/160713wufr33xjicgnjiqo.png) 下载地址中的IP填写软件仓库的私有IP。 ------------ ## 6 服务调测 申请服务成功,资源栈详情页面如下: ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202112/28/1607472b5cfeizyfhk9ivc.png) ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202112/28/160757mkg4pwxiy08nwegw.png) ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202112/28/160807ins2cx4fta1j1fhf.png) ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202112/28/160815o4gzk4g2tmzqz8il.png) ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202112/28/160830alyqgs2seiudn1vb.png) ------------ 本示例通过脚本自动将Redis安装成功。远程登录redis主节点虚拟机,按如下步骤操作验证(redis从节点操作同理): 1) 进入redis安装目录,执行命令src/redis-cli -c -p 7000 -h 192.168.1.108【其中7000为redis的主节点1端口号,192.168.1.108是主服务器的IP地址】,再输入命令set key value放入一个键值对,再执行命令get key获取刚才的值; 2) 最后输入命令cluster nodes查看集群状态 ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202112/28/160943ekswwuzssnko2dqk.png) ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202112/28/160950v6nsl1iaathbqr4s.png) ------------ 感谢大家观看,欢迎下方留言交流! ------------
  • [服务构建器] 【华为云Stack ManageOne 服务构建器】通过服务构建器申请安装一个Redis单机版服务
    ## 1 背景信息 本文档以服务构建器部署Redis为例,演示如何通过服务构建器自动化部署Redis服务 。 ## 2 业务分析 弹性云服务器(ECS)中安装Redis,Redis是一个开源(BSD许可), 内存数据结构存储,可用作数据库,缓存和消息代理。 ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202112/28/1519393gwymzfoanzoif4k.png) ### 3.1 镜像 CentOS 7.9 (x86_64)已预置gcc环境,且成功安装Cloud-Init。 ### 3.2 软件包 请提前准备以下软件包。 | 软件包名称 | 说明 | | ------------------ | ------------------------------------------------------------ | | redis-6.2.6.tar.gz | Redis的安装文件。 官网下载路径参考:https://download.redis.io/releases/redis-6.2.6.tar.gz | ## 4 规划配置 ### 4.1 资源规划 1. 网络规划 | 资源 | 具体操作 | | ---------- | -------------------------------------- | | 虚拟私有云 | 在虚拟私有云Console提前申请VPC和子网。 | 2. 弹性云服务器:需要一台弹性云服务器安装Redis,具体配置如下。 | 资源 | 推荐配置 | | ---------- | -------- | | 内存 | 4G | | vCPUs | 2 | | 系统盘大小 | 20G | ### 4.2 模板设计 本次模板设计使用服务构建器图形化设计器 ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202112/28/152002iheh1sd6hgbbipzm.png) #### 模板资源节点说明 | 节点名称 | 资源类型 | 作用 | | ---------------- | ------------------------ | ----------------------------------- | | CloudServer1d9k7 | HCS::ECS::CloudServer | Redis服务器 | | MultipartMime | OS::Heat::MultipartMime | 关联Redis虚拟机和SoftwareConfig资源 | | SoftwareConfig | OS::Heat::SoftwareConfig | 安装Redis脚本配置文件 | #### 模板参数节点说明 #### 服务器基础配置 | 参数Label | 参数名称 | 参数说明 | | ---------- | ------------------------ | ----------------------------- | | 可用分区 | availability_zone_kukenj | | | 镜像 | image_1mas5d | | | 规格 | flavor_3tw9c7 | 包括内存、CPU、磁盘类型等信息 | | 磁盘类型 | volume_type_i8k3xm | 云硬盘类型 | | 容量 | size_9z88cy | | | 服务器名称 | name_bm2leo | | #### 服务器网络配置 | 参数Label | 参数名称 | 参数说明 | | --------- | ---------------- | ------------------------------------------------------------ | | 子网 | subnet_id_7mzv95 | 弹性云服务器的网卡ID。需要指定vpc_id对应VPC下已创建的网络(network)的ID,UUID格式。 | #### Redis软件配置 | 参数Label | 参数名称 | 参数说明 | | ------------- | ------------------------- | ------------------------------------------------------------ | | Redis下载地址 | redis_source_url_i427qp | Redis安装包的下载地址。(例如:http://[软件源云服务器私有IP]/packages/ redis-5.0.3.tar.gz) | | Redis安装路径 | redis_install_path_x3sci5 | Redis安装路径 | #### 输出信息节点说明 | 输出信息 | 描述 | | ------------ | ----------------------- | | 服务器IP地址 | Redis服务器的私有IP地址 | | 默认端口号 | Redis数据库的默认端口号 | ### 4.3 脚本设计 1. 脚本内容 ```shell #!/bin/bash REDIS_SOURCE_URL=redis_source_url REDIS_INSTALL_PATH=redis_install_path # 默认值为/usr/local/redis REDIS_SOURCE_PATH=/opt LOG_PATH=/var/log/redis_install.log echo "Start to execute install redis script." >>${LOG_PATH} cd ${REDIS_SOURCE_PATH} #redis REDIS_PACKAGE_NAME=${REDIS_SOURCE_URL##*/} wget -qc ${REDIS_SOURCE_URL} -O ${REDIS_PACKAGE_NAME} echo "Download redis package success." >>${LOG_PATH} tar -zxvf ${REDIS_PACKAGE_NAME} rm ${REDIS_PACKAGE_NAME} REDIS_SRC_FOLDER=${REDIS_PACKAGE_NAME%.tar.gz} cd ${REDIS_SRC_FOLDER} echo "Start to execute make && make install to compile." >>${LOG_PATH} make >>${LOG_PATH} make install PREFIX=${REDIS_INSTALL_PATH} >>${LOG_PATH} echo "Compile success." >>${LOG_PATH} cp ${REDIS_SOURCE_PATH}/${REDIS_SRC_FOLDER}/redis.conf ${REDIS_SOURCE_PATH}/${REDIS_SRC_FOLDER}/redis.conf.bak echo "Start to post install config." >>${LOG_PATH} sed -i 's/daemonize no/daemonize yes/' ${REDIS_SOURCE_PATH}/${REDIS_SRC_FOLDER}/redis.conf sed -i 's/bind 127.0.0.1 -::1/# &/g' ${REDIS_SOURCE_PATH}/${REDIS_SRC_FOLDER}/redis.conf sed -i 's/protected-mode yes/protected-mode no/' ${REDIS_SOURCE_PATH}/${REDIS_SRC_FOLDER}/redis.conf echo "End post install config." >>${LOG_PATH} cp ${REDIS_SOURCE_PATH}/${REDIS_SRC_FOLDER}/redis.conf ${REDIS_INSTALL_PATH}/bin/ firewall-cmd --zone=public --add-port=6379/tcp --permanent firewall-cmd --reload echo "Start redis service." >>${LOG_PATH} cd ${REDIS_INSTALL_PATH}/bin nohup ./redis-server redis.conf 2>&1 & echo "Execute install redis script success." >>${LOG_PATH} ``` 2. 脚本输入参数说明 | 参数Label | 参数名称 | 参数说明 | | ------------- | ------------------ | ------------------------------------------------------------ | | Redis下载地址 | redis_source_url | Redis安装包的下载地址。(例如:http://[软件源云服务器私有IP]/packages/ redis-6.2.6.tar.gz) | | Redis安装路径 | redis_install_path | Redis安装路径(例如: /usr/local/redis ) | ## 5 申请资源栈 ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202112/28/152029euszfwxllvosh2hj.png) ## 6 服务调测 本示例通过脚本自动将Redis安装成功,可以看到redis服务正常。 ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202112/28/152046gxtmrn11hxpgmsal.png)
  • [交流吐槽] 关于幂等性的学习笔记
    最基础的概念,什么是幂等性?幂等性:提交多次的情况下,结果都一样。比如数据库查询,可称为天然幂等性,即查询多次结果都一样,无需人为去做幂等性操作。但是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系列】解读高斯Redis的技术架构与应用场景
    >摘要:高斯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在**成本、可用容量、吞吐、压缩上**都有非常大的优势: ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202112/17/095911cbvm4srodzaorfln.png) 注:比较相同数据容量(约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、块存储,还有数据库族、大数据族都依赖于此,可想它的强大及稳定性。 ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202112/17/100008szrlqoqlzxhp9gqd.png) 高斯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的相关命令,让用户获取骑手的实时位置,骑手也能找到附近可配送的订单,最终顺利将用户的外卖送到用户。 ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202112/17/1003358ra7kwoc2dzwwzrf.png) # 计数 社交平台每条热搜记录的搜索量数值;用户注册一个帐号后,网站记录的关注数、粉丝数、动态数;一个接口一分钟被限制100次请求等。这些数据背后,是一个个计数器在工作。 计数是典型的强一致应用场景,比如电商在秒杀活动中,往往会搭建Redis主从集群给下层MySQL做缓存,用Redis的计数器功能抵住流量压力。 所以如果数据发生不一致,计数器就会得到错误的信息,整个数据库可能面临崩溃的危险。但原生Redis的主从同步是异步的,当主节点写入数据后,从节点不保证立刻更新数据,如果此时读取数据,读到的就是过期的旧数据,产生数据不一致问题。高斯Redis则可以把全量数据下沉到强一致共享存储池,彻底摒弃了开源Redis的异步复制机制。另外,计算层将海量数据进行分片,在故障场景下,自动进行接管,实现了服务的高可用。 # 即时通讯 即时通讯(简称IM)是一个实时通信系统,允许两人或多人使用网络实时的传递文字消息、文件、语音与视频。它最核心的是消息系统,包括聊天消息的同步、存储和检索。而消息存储库和同步库又对存储层的性能有很高的要求:要能支撑海量消息数据的永久存储,具备极高的写入吞吐能力,尽可能低的读取延迟等等。 综上,存储层的性能会直接影响到IM系统的用户体验。高斯Redis在性能和规模上可以满足IM系统对存储层的严格要求,它作为IM系统的存储层,可以将大量的随机写转换为顺序写,提升数据写入性能,再通过读缓存、bloom filter优化读取性能。 下图是一个基于高斯Redis的IM应用案例,使用的是Stream作为基本数据结构。创建一个群聊时,在Redis中对应地为该群聊创建一个Stream队列。在发送消息时,每个用户都将消息按照时间顺序添加到Stream队列中,保证了消息的有序性。 ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202112/17/100356ptd8h5b5y1s9ia5k.png) 这个应用中涉及到了一种数据类型——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作为特征数据库。 ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202112/17/100428dgfnsewbjojyxfxv.png) 在线上推理的特征生产(抽取、处理、存储)中,特征平台会定时调度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系列合集。
  • [交流分享] 关于幂等性的学习笔记
    最基础的概念,什么是幂等性?幂等性:提交多次的情况下,结果都一样。比如数据库查询,可称为天然幂等性,即查询多次结果都一样,无需人为去做幂等性操作。但是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 数据类型
    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,用强一致提供可靠保障
    >摘要:其实开源Redis的弱一致性已经不满足很多应用场景的诉求。怎么,不信?本文分享自华为云社区[《华为云企业级Redis揭秘第15期:Redis为什么需要强一致?》](https://bbs.huaweicloud.com/blogs/312935?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=database&utm_content=content),作者: 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),它的部署方式如下: ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202111/27/105205p4vfwitamwiquitg.png) MHA由管理服务和Node服务组成,Node服务部署在每个MySQL节点上,MHA组件负责让MySQL的从库尽可能的追平主库,提供主从一致的状态。发生故障进行主从切换时,Manager首先为从库补充落后的数据,然后再将用户访问切换到从库,这个过程可能长达数十秒。 MHA的部署和维护都相当复杂,如未能顺利执行故障切换或发生数据丢失,运维面临的场面都将很棘手。其实运维同学何尝不希望手中的系统稳定运行呢?要是数据库自身能提供强一致保障,何苦再依赖复杂的辅助组件! # 2. 什么是强一致 上一节中笔者介绍了弱一致带来各种问题,接下来这一节具体介绍下什么是强一致。在“分布式系统”和“数据库”这两个领域中,一致性都是重要概念,但它表达的内容却并不相同。对于分布式系统而言,一致性是在探讨当系统内的一份逻辑数据存在多个物理的数据副本时,对其执行读写操作会产生什么样的结果,这也符合 CAP 理论对一致性的表述。而在数据库领域,“一致性”与事务密切相关,又进一步细化到 ACID 四个方面。因此,当我们谈论分布式数据库的一致性时,实质上是在谈论事务一致性和数据一致性两个方面。 **2.1 事务一致性** 事务的一致性主要是指的事务的ACID,分别是原子性、一致性、隔离性和持久性,如下图所示: ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202111/27/105235mfrof7gbprhdpano.png) - 原子性:事务中的所有变更要么全部发生,要么一个也不发生,通过日志技术实现; - 一致性:事务要保持数据的完整性,它是应用程序的属性,依赖原子性和隔离属性来实现; - 隔离性:多事务并行执行所得到的结果,与串行执行(一个接一个)完全相同,通过并发控制技术来实现; - 持久性:一旦事务提交,它对数据的改变将被永久保留,不应受到任何系统故障的影响,通过日志技术实现。 **2.2 数据一致性** 在分布式系统中,为了避免网络不可靠带来的问题,通常会存储多个数据副本,逻辑上的一份数据存储在多个物理副本上,自然带来了数据一致性问题。 **(1)状态视角** 从状态的视角来看,任何变更操作后,数据只有两种状态,所有副本一致或者不一致。在某些条件下,不一致的状态是暂时,还会转换到一致的状态,而那些永远不一致的情况几乎不会去讨论,所以习惯上大家会把不一致称为“弱一致”。相对的,一致就叫做“强一致”了。以一个一主两备的MySQL集群为例,“强一致”的交互过程如下: ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202111/27/105303hhyvfrv29gtfnhud.png) 在该模式下,主库与备库同步 binlog 时,主库只有在收到两个备库的成功响应后,才能够向客户端反馈提交成功。显然,用户获得响应时,主库和备库的数据副本已经达成一致,所以后续的读操作肯定是没有问题的,这就是状态视角的“强一致”的模型。 但是状态视角的这种强一致副作用很大:第一个是性能很差,主库必须要等备库1和备库2成功返回后才能返回;第二个是可用性问题,如果主备节点很多,出现故障的概率非常高。因此,状态视角的强一致代价非常大,所以很少使用。 **(2)操作视角** 状态视角的强一致降低了系统的可用性,因此很多系统选择状态视角的弱一致性模型,通过额外的算法(如Raft、Paxos)在不保证所有节点状态的一致的情况下,来保证操作视角的一致性,同时提高了系统的可用性。通过加入一些限定条件,衍生出了若干种一致性模型: ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202111/27/105328zsof87lfgcelgayz.png) - 线性一致性:操作视角实现真正的强一致 - 顺序一致性:一致性强度弱于线性一致性 - 因果一致性:一致性强度弱于顺序一致性 - 写后读一致性:一致性强度相当,弱于因果一致性 # 3. 强一致的刚需场景 上一节我们介绍了什么是强一致,这一节我们介绍下强一致的典型应用场景。 在常见的互联网应用中,如果数据库服务器只部署在单个节点上,那么应用程序所有的读和写都只会访问单个节点,一份逻辑数据在物理上也只有一份,这种场景下就谈不上强一致的问题。 但是随着系统中业务访问量的增加,如果是单机部署数据库,就会导致I/O访问频率过高,数据库就会成为系统的瓶颈。此时,为了降低单机磁盘的I/O访问频率,提高单个机器的I/O性能,通常会增加多个数据存储节点,形成一主一从或者一主多重的架构, 此时,我们可以将负载分布在多个从节点上,一方面可以实现读写分离,写请求访问主库,读请求访问备库。另一方面,还可以在主库如果出现宕机的情况下进行主备切换,增强系统的稳定性。在以上两个场景中,由于一份逻辑数据在物理上有多个副本,那么如何保证多个副本之间的数据一致呢,这就是强一致需要解决的问题。 **3.1 读写分离场景** 以关系型数据库MySQL为例,典型的部署方案为一主两从三节点方案,主节点负责处理写操作,两个从节处理读操作,分担主库的压力,如下图所示: ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202111/27/105408qahmi448cckjj8il.png) 此时,如果系统没有实现强一致,就有可能会遇到执行完写操作后,立刻去读,然后发现读不到或者读到旧状态的尴尬场景,比如操作顺序为以下操作: - 客户端首先通过代理向主节点 Master 进行了写入操作,此时由于没有实现强一致,写操作写完后立即返回; - 紧接着第二步去从节点 Slave A 执行读操作,此时Master和Slave A之间的同步还未完成,系统处于非强一致的状态,所以第二步的读操作读取到了旧状态。 可以看出,在一主多备读写分离的场景下,如果想要保证写入和读取操作的准确无误,系统实现强一致是非常重要的。 **3.2 主备切换场景** 主备切换的场景也需要强一致来保证,以目前业内使用最广泛的内存数据库Redis为例,Redis的主从同步如下图所示: ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202111/27/105435muypaefrtkyetier.png) 从上图可以看出,当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的整体架构如下: ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202111/27/105502othnq4czrw5lgcrx.png) 相比开源Redis,高斯Redis采用存算分离的设计思想,计算层负责计算和协议的处理,聚焦服务。而存储层负责副本管理、扩缩容等处理,聚焦数据本身。高斯Redis的优势如下: - 数据强一致:存储层使用分布式存储DFV,轻松实现了3副本强一致; - 超可用:N个节点的集群最多可以挂掉N – 1个节点; - 低成本:数据采用磁盘存储并且进行压缩,每GB的成本不到开源Redis的十分之一; - 秒扩容:计算层仅需修改路由映射,无需数据搬迁,实现秒级扩容; - 自动备份:高斯Redis可以实现MVCC快照备份和定期自动备份。 **4.2 高斯Redis强一致的实现** 开源Redis和高斯Redis的架构如下图所示: ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202111/27/105521nphlyi98gmr6xd4z.png) # 5. 结语 我们在做架构设计的时候,其实很多场景都隐藏着强一致的诉求。如朋友圈这类应用,如果没有实现强一致,朋友圈的评论很容易乱序。再比如限流器的场景,如果没有强一致的保证,也极容易造成数据库的崩溃。因此,必须在系统设计之初就认识到强一致的重要性,才能设计出更加稳定和可靠的系统。而高斯Redis基于存算分离的架构设计,实现了数据的强一致,为业务的稳定可靠提供了超强保障。
  • [沃土-方案构建经验分...] CCE云服务-咨询—docker 容器中运行redis无法启动:ignore-warnings ARM64-COW-BUG报错
    【故障现象】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搭建高性能网盘
    随着计算机硬件性能的提高,企业对数据保存量的要求不断提高。使用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
  • [技术干货] 多段并行处理之Pipeline(管道)
    之前一直在写相关的代码注释,读了一些相关资料,有了一些个人的见解,花费了一段时间进行总结,与各位分享一下,知识浅薄,还有许多未理解之处,欢迎各位纠正、讨论。 路径:mindspore\ccsrc\pipeline ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202111/01/105158c8lh935lwxfps0oz.png) 在深度学习中,当数据集和参数量的规模越来越大,训练所需的时间和硬件资源会随之增加,最后会变成制约训练的瓶颈。分布式并行训练,可以降低对内存、计算性能等硬件的需求,是进行训练的重要优化手段。 MindSpore提供了分布式并行训练的功能,它支持了包括数据并行和自动并行在内的多种并行模式。随着深度学习的快步发展,为了提升神经网络的精度和泛化能力,数据集和参数量都在呈指数级向上攀升。分布式并行训练成为一种解决超大规模网络性能瓶颈的发展趋势。MindSpore支持了当前主流的分布式训练范式并开发了一套自动混合并行解决方案。 Pipeline,你土味一点你把它翻译成一条龙服务专业一点,叫它综合解决方案,就行。 ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202111/01/105212wu15vdw6uixw3i7m.png) 对于算法或者大数据分析里的可重复使用,针对新的数据,直接输入数据,可以得到结果。 近年来,神经网络的规模几乎是呈指数型增长。受单卡内存的限制,训练这些大模型用到的设备数量也在不断增加。受server间通信带宽低的影响,传统数据并行叠加模型并行的这种混合并行模式的性能表现欠佳,需要引入流水线并行。流水线并行能够将模型在空间上按stage进行切分,每个stage只需执行网络的一部分,大大节省了内存开销,同时缩小了通信域。MindSpore能够根据用户的配置,将单机模型自动地转换成流水线并行模式去执行。pipeline_stages用来设置流水线并行的stage个数。 代码样例如下: ```cpp from mindspore import context context.set_auto_parallel_context(pipeline_stage=4) context.get_auto_parallel_context("pipeline_stage") ``` 数据是整个深度学习中最重要的一环,因为数据的好坏决定了最终结果的上限,模型的好坏只是去无限逼近这个上限,所以高质量的数据输入,会在整个深度神经网络中起到积极作用,数据在整个数据处理和数据增强的过程像经过pipeline管道的水一样,源源不断地流向训练系统,如图所示: ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202111/01/105231p1uuremn6lg91a1y.png) 相关文献https://www.mindspore.cn/docs/programming_guide/zh-CN/r1.3/operators.html MindSpore为用户提供了数据处理以及数据增强的功能,在数据的整个pipeline过程中,其中的每一步骤,如果都能够进行合理的运用,那么数据的性能会得到很大的优化和提升。本次体验将基于CIFAR-10数据集来为大家展示如何在数据加载、数据处理和数据增强的过程中进行性能的优化。 此外,操作系统的存储、架构和计算资源也会一定程度上影响数据处理的性能。 在计算机视觉任务中,图像数据往往因为容量限制难以直接全部读入内存。MindSpore提供的mindspore.dataset模块可以帮助用户构建数据集对象,分批次地读取图像数据。同时,在各个数据集类中还内置了数据处理和数据增强算子,使得数据在训练过程中能够像经过pipeline管道的水一样源源不断地流向训练系统,提升数据训练效果。 此外,MindSpore还支持分布式场景数据加载,用户可以在加载数据集时指定分片数目,具体用法参见数据并行模式加载数据集。 在深度学习中,当数据集和参数量的规模越来越大,训练所需的时间和硬件资源会随之增加,最后会变成制约训练的瓶颈。分布式并行训练,可以降低对内存、计算性能等硬件的需求,是进行训练的重要优化手段。根据并行的原理及模式不同,业界主流的并行类型有以下几种: 数据并行(Data Parallel):对数据进行切分的并行模式,一般按照batch维度切分,将数据分配到各个计算单元(worker)中,进行模型计算。 模型并行(Model Parallel):对模型进行切分的并行模式。MindSpore中支持层内模型并行模式,即对参数切分后分配到各个计算单元中进行训练。 混合并行(Hybrid Parallel):指涵盖数据并行和模型并行的并行模式。 当前MindSpore也提供分布式并行训练的功能。它支持了多种模式包括: DATA_PARALLEL:数据并行模式。 SEMI_AUTO_PARALLEL:半自动并行模式。用户对算子手动配置切分策略实现并行,它融合了数据并行、模型并行及混合并行。 AUTO_PARALLEL:自动并行模式,该模式为实验特性,当前只在部分网络验证。自动并行可以自动建立代价模型,找到训练时间较短的并行策略,为用户选择1种并行模式。MindSpore提供了如下的两种不同的策略搜索算法: dynamic_programming :动态规划策略搜索算法。能够搜索出代价模型刻画的最优策略,但在搜索巨大网络模型的并行策略时耗时较长。其代价模型是围绕Ascend 910芯片基于内存的计算开销和通信开销对训练时间建模。 recursive_programming :双递归策略搜索算法。对于巨大网络以及大规模多卡切分能够保证瞬间生成最优策略。其基于符号运算的代价模型可以自由适配不同的加速器集群。 HYBRID_PARALLEL:在MindSpore中特指用户通过手动切分模型并基于通信原语实现混合并行的场景。 一个典型的机器学习构建包含若干个过程 1、源数据ETL 2、数据预处理 3、特征选取 4、模型训练与验证 以上四个步骤可以抽象为一个包括多个步骤的流水线式工作,从数据收集开始至输出我们需要的最终结果。 因此,对以上多个步骤、进行抽象建模,简化为流水线式工作流程则存在着可行性,下载数据,解压数据,根据标签把数据分到不同目录的工作对利用spark进行机器学习的用户来说,流水线式机器学习比单个步骤独立建模更加高效、易用。 管道机制实现了对全部步骤的流式化封装和管理(streaming workflows with pipelines)。注意:管道机制更像是编程技巧的创新,而非算法的创新。 管道机制在机器学习算法中得以应用的根源在于,参数集在新数据集(比如测试集)上的重复使用。 redis客户端执行一条命令分4个过程: 发送命令-〉命令排队-〉命令执行-〉返回结果 这个过程称为Round trip time(简称RTT, 往返时间),mget mset有效节约了RTT,但大部分命令(如hgetall,并没有mhgetall)不支持批量操作,需要消耗N次RTT ,这个时候需要pipeline来解决这个问题。其目的是将一批命令打包到一个内部维护的queue里,然后建立socket与server交互,这时候是只会发送一次命令,也就是只会交互一次,然后queue内的命令都执行完后会一起返回结果,这样大大减少了通信的次数,自然降低了通信所耗费的时间。queue是先进先出,所以可以保证执行顺序。 Redis 的 pipeline(管道)功能在命令行中没有,但 redis 是支持 pipeline 的,而且在各个语言版的 client 中都有相应的实现。 由于网络开销延迟,就算 redis server 端有很强的处理能力,也会由于收到的 client 消息少,而造成吞吐量小。当 client 使用 pipelining 发送命令时,redis server 必须将部分请求放到队列中(使用内存),执行完毕后一次性发送结果;如果发送的命令很多的话,建议对返回的结果加标签,当然这也会增加使用的内存; 通信模型 ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202111/01/105301zpdpoqxezrbwjl4a.png) ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202111/01/105311ozc0hk6comwcfpiv.png) ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202111/01/1053349fokdnusvrzdsxkl.png) 流水线 ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202111/01/105358xmelyfcncezhxxct.png) ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202111/01/105414enm7ray9ozefhn7m.png) Pipeline 在某些场景下非常有用,比如有多个 command 需要被“及时的”提交,而且他们对相应结果没有互相依赖,对结果响应也无需立即获得,那么 pipeline 就可以充当这种“批处理”的工具;而且在一定程度上,可以较大的提升性能,性能提升的原因主要是 TCP 连接中减少了“交互往返”的时间。 不过在编码时请注意,pipeline 期间将“独占”链接,此期间将不能进行非“管道”类型的其他操作,直到 pipeline 关闭;如果你的 pipeline 的指令集很庞大,为了不干扰链接中的其他操作,你可以为 pipeline 操作新建 Client 链接,让 pipeline 和其他正常操作分离在2个 client 中。不过 pipeline 事实上所能容忍的操作个数,和 socket-output 缓冲区大小/返回结果的数据尺寸都有很大的关系;同时也意味着每个 redis-server 同时所能支撑的 pipeline 链接的个数,也是有限的,这将受限于 server 的物理内存或网络接口的缓冲能力。 简介   Redis 使用的是客户端-服务器(CS)模型和请求/响应协议的 TCP 服务器。这意味着通常情况下一个请求会遵循以下步骤: 客户端向服务端发送一个查询请求,并监听 Socket 返回,通常是以阻塞模式,等待服务端响应。服务端处理命令,并将结果返回给客户端。  Redis 客户端与 Redis 服务器之间使用 TCP 协议进行连接,一个客户端可以通过一个 socket 连接发起多个请求命令。每个请求命令发出后 client 通常会阻塞并等待 redis 服务器处理,redis 处理完请求命令后会将结果通过响应报文返回给 client,因此当执行多条命令的时候都需要等待上一条命令执行完毕才能执行。比如: ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202111/01/105514muzevvocc9sinqyi.png) 其执行过程如下图所示: ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202111/01/105524qbqugzemlqowwv5l.png)  由于通信会有网络延迟,假如 client 和 server 之间的包传输时间需要0.125秒。那么上面的三个命令6个报文至少需要0.75秒才能完成。这样即使 redis 每秒能处理100个命令,而我们的 client 也只能一秒钟发出四个命令。这显然没有充分利用 redis 的处理能力。  而管道(pipeline)可以一次性发送多条命令并在执行完后一次性将结果返回,pipeline 通过减少客户端与 redis 的通信次数来实现降低往返延时时间,而且 Pipeline 实现的原理是队列,而队列的原理是时先进先出,这样就保证数据的顺序性。 Pipeline 的默认的同步的个数为53个,也就是说 arges 中累加到53条数据时会把数据提交。其过程如下图所示:client 可以将三个命令放到一个 tcp 报文一起发送,server 则可以将三条命令的处理结果放到一个 tcp 报文返回。 ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202111/01/1055369phyj49w7187i5r0.png) ![image.png](https://bbs-img.huaweicloud.com/data/forums/attachment/forum/202111/01/1142532ssrihpyfcrfkbmf.png) 需要注意到是用 pipeline 方式打包命令发送,redis 必须在处理完所有命令前先缓存起所有命令的处理结果。打包的命令越多,缓存消耗内存也越多。所以并不是打包的命令越多越好。具体多少合适需要根据具体情况测试。 大量 pipeline 应用场景可通过 Redis 脚本(Redis 版本 >= 2.6)得到更高效的处理,后者在服务器端执行大量工作。脚本的一大优势是可通过最小的延迟读写数据,让读、计算、写等操作变得非常快(pipeline 在这种情况下不能使用,因为客户端在写命令前需要读命令返回的结果)。 相关白皮书(技术指导)[优化数据处理](https://www.mindspore.cn/docs/programming_guide/zh-CN/r1.3/optimize_data_processing.html?highlight=pipeline "优化数据处理"):