Redis是一种在内存中运行的数据结构存储系统。 它可以用作数据库、缓存或消息中间件，支持多种类型的数据结构。
与传统金融系统相比，互联网金融系统更注重系统的高并发访问和海量数据的处理，以及传统金融中数据处理的可靠性和连续性。 会计核心系统是互联网金融系统中非常重要的系统。 承载金融业务的开发、业务流程的批量处理、账务核对、客户贷款期限、利息及罚息计算、还款计划等。 生成等重要功能。 随着金融业务日益广泛、客户数量增多、会计数据规模庞大，给会计处理工作带来巨大压力，造成严重影响业务正常运转。
本文主要介绍REDIS内存数据库集群的特点及其在互联网财务会计核心系统中的应用实践以及问题的解决方案。
1.Redis的技术特点及演进
Redis是一个开源的、网络化的、基于内存的存储系统，可以进行数据持久化KEY-VALUE。 Redis通过将KEY映射到VALUE来构建字典来保存数据。 它支持多种存储类型，包括LIST、SET、SORT SET和HASH。 它可以对这些数据类型执行许多原子操作。 Redis 将数据存储在内存中，它发送给 Redis 的命令请求不需要经过典型的查询分析器（）或查询优化器（）处理，因此 Redis 对其存储的数据执行随机读写的速度非常快。 的。
随着互联网时代的进步和大数据时代的到来，Redis的版本也发生了翻天覆地的变化。 从key过期时间的逐步细化、增量复制的实现，到分布式集群Redis的推出，LUA脚本的功能不断增强，再到4.0版本的支持，可以看出Redis的发展已经接受了更多数据处理趋势。 在此背景下，如何应对当前互联网财务会计核心应用高并发、海量数据快速计算、快速响应数据结果的需求？ Redis的使用提供了一个优秀的解决方案，通过将数据和请求分发到不同的节点来实现水平扩展和负载均衡，从而提供高并发、数据吞吐量和快速响应能力。
目前主流的Redis集群方案有主从三种，由于它们都是基于主从的扩展，所以这里我们只分析和。
1. 集群
0.6版本推出了高可用性（HA）解决方案。 当Redis作为-SLAVE的高可用方案时，无法提供服务。 Redis本身无法实现自动主从切换，所以它承担了监视器的功能。 它可以监控多个SALVE集群，并可以选择多个SALVE之一作为新的SALVE。 其他 SALVE 节点会将其跟随的地址更改为已提升的 SALVE 的新地址。 拓扑图如下。
集群数据同步的原理依然延续主从模式：
(1)当从节点向主节点发送SYNC命令时；
（2）主节点收到命令后，执行保存快照的命令，创建持久化文件，并在持久化文件创建过程中缓存命令；
(3)主节点执行命令后，将持久化文件发送给从节点； (4)从节点收到持久化文件后，开始接收主节点的命令缓存；
(5)上述步骤完成后，主节点每次进行写操作都会发送给从节点。 具体流程图如下：
2. 集群
集群是.0版本引入的功能，是基于Redis的分布式实现。 它引入了哈希槽的概念，支持动态添加或删除节点，并且可以线性扩展至1000个节点。 数据在多个Redis节点之间共享。 当某些节点不可达时，集群仍然可用。 数据是异步复制的，数据没有保证。 具有很强的一致性和自动化能力。 客户端直接连接Redis，消除了PROXY性能的消耗。
Redis是去中心化的结构，拓扑如下图所示。 所有节点相互连接，通过协议发布广播消息，每隔一段时间互相发送PING/PONG心跳包，检测其他节点的状态，保持信息同步。 客户端直接连接任意Redis，客户端通过Redis路由进行转发。 向实际请求数据的节点发出请求。
集群数据同步的原理依然延续了主从模式。 这里我不再重复描述。 这里我重点讲一下集群的路由原理。 Redis节点在操作KEY时，不使用代理模式，直接找到KEY所在的节点并执行命令。 相反，它将客户端重定向到存储 KEY 的节点。 客户端通过对KEY进行操作，会记录路由地址，最终客户端获取负责各个节点的KEY的最新信息。 这也用流程图进行了简要描述。
所以一般来说，对于给定的操作，客户端将直接连接到正确的节点并执行命令。 与单点Redis不同，集群引入了哈希槽的概念，并且不是通过一致性哈希来实现的。 总共有16384个哈希槽。 每个节点只负责哈希槽的一部分，每个KEY使用=CRC16(KEY)384来计算它属于哪个节点。
三、总结
我们先来看看两种聚类方法在技术指标上的差异。
鉴于技术指标的重点，该模型更偏向于高可用CACHE和存储场景； 该模型用户的高可用需求场景更偏向高可用CACHE和大数据量的存储场景。 因此，在核心的互联网财务会计系统中，更优选REDIS。
2、Redis在核心互联网金融记账系统中的一些应用场景
互联网财务会计核心系统是一个特殊的会计系统。 与传统金融的会计核心相比，它具有很强的数据一致性和业务耦合性，具有数据传输的合规性，也适用于某些场景。 访问密度高。 下面列出了Redis在核心互联网财务会计系统中的一些典型应用场景。
1. 分享
它是一种记录客户端状态的机制。 它与保存在客户端浏览器中不同，而是保存在服务器上。 当客户端浏览器访问服务器时，服务器会以某种形式将客户端信息记录在服务器上。 即当客户端和服务器需要再次交互时，只需要查找客户端的状态即可。
如下图所示，用户请求首先会到达负载均衡器。 负载均衡器根据路由策略将请求分发到后端服务实例。 这会导致第一个请求被交给实例M，下一个请求可能会到实例M。N，如果不做共享，到达实例N的请求将被返回给客户端处理。
多个服务和服务器之间共享，可以实现多站点单点登录，还可以实现单点登录的踢出功能。
2. 获取活动门票
活动抢优惠券是互联网金融公司最常用的营销手段。 对于互联网金融公司来说，这种业务场景带来了几个需要解决的问题，包括系统并发压力大； 大量用户抢同一张优惠券带来数据一致性问题； 优惠券不可超额发放或重新发放； 由于优惠券涉及资金，因此也存在资金安全问题。 可见，该场景的主要技术挑战是高并发、高响应、一致性、安全性等。
我们引用了电力行业的一个措施，叫“削峰填谷”。 顾名思义，就是在系统负载较低的情况下，在流量高峰到来之前，进行冷热数据交换和优惠券数据预热，以分担优惠券领取的负担。 活动结束后并发流量高。 优惠券销售活动的业务特点是经常性的高峰流量对相关系统造成巨大的并发访问影响。 这里，从业务场景来看，如下图所示。
（1）提前存储访问量，预热活跃用户，减少活动开始后的登录和风控压力。
（2）在Redis上进行全局数据处理，基于Redis内存的高读写、高QPS特性，解决热点数据的高并发问题。 热点数据存储在内存中，利用Redis特性进行多分片部署。 高并发读写特性提高了系统吞吐量。 下图展示了热点数据的结构和场景描述。
（3）分布式锁的应用中，在抢优惠券的过程中，可能会出现多个用户同时抢同一张优惠券，或者同一用户抢多张优惠券的问题。 当用户点击过快时，有可能同一用户的两个线程同时通过了优惠券资格验证。 在这种情况下，用户可以同时抢到两张优惠券。 针对这个问题，我们通过在优惠券号和用户账号两个维度添加分布式锁来解决。 根据REDIS的锁服务设计，锁在数据结构上使用了REDIS最简单的KEY。 核心是建立锁和释放锁，保证绝对安全。 最简单的方法是使用 GET 来检查锁。 当无法获取信息时，使用SET设置锁。 这种方法最简单，但是应用场景比较有限，无法保证排它锁，因为在高并发场景下，GET和SET之间的毫秒级延迟无法保证其他线程执行GET和SET操作。
针对这种风险，我们的锁设计考虑使用SET NX PX来实现，如下：SET KEY唯一随机值NX PX固定毫秒。 设置KEY的值，只有不存在时才会生效，并将生存期设置为固定毫秒。 与 KEY 关联的 VALUE 值在所有客户端和所有锁定请求中必须是唯一的。 使用唯一的随机值的目的是为了更安全地释放锁。 删除KEY值，添加逻辑，前提是KEY值存在且VALUE值是线程对应的唯一值。 具体的加锁实现方法如下。
3. 支付渠道限制
该场景是支付路由场景中支付通道限制的设计。 是为了避免在进行通道路由支付时，资金不足时通道控制缺失，导致大量交易失败和处理异常。 下面是一个路由示例图。
例如，通道A的路由比例为70%，通道B的路由比例为30%。 当支付请求过多时，通道A的资金额度耗尽将导致通过通道A的支付交易失败。 因此，需要计算配额并恢复配额金额。 。 基于事务数据的强一致性和准确性，我们采用Redis命令的原子特性，即事务中的所有操作要么全部完成，要么未完成，不会在某个中间环节结束。 具体操作规范如下。
3、Redis使用中遇到的一些问题
在海量数据、高并发的场景下，如何用好Redis，约束KEY规范，合理确定VALUE的值； 合理设置参数大小，如，，； 合理分配缓存过期时间； 合理锁定和控制分布式单线程数据库查询写入缓存操作等。这里描述一下海量数据、高并发场景下遇到的一些问题。
1. 大价值问题
背景：某个时间点，业务监控到大量告警。 经排查，业务系统连接Redis，报大量TOO MANY。
经排查，发现业务系统与REDIS连接异常，网络吞吐量异常高。 经过查看源码，我们发现当出现TION或PTION时，会抛出此类异常，所以我们重点分析这两种异常场景。 TION 顾名思义，连接 REDIS 时出现错误。 当连接节点1时，客户端仍然尝试连接节点2。客户端会推断整个集群FAILD会抛出异常，中断当前连接。 PTION的产生有两种异常，一种是MOVED异常，另一种是ASK异常。 可以推断，MOVED是由于节点迁移而无法识别哈希槽引起的，而ASK是某个槽被设置为状态时的情况。 节点收到命令后才会收到该槽位的命令请求。
Redis内部检查过程中，内部节点连接没有异常，INFO状态也正常。 综合以上分析，异常场景可能导致主从节点切换、迁移，网络因素可能导致槽位信息更新失败。 经过验证，我们发现Redis主节点的网卡流量巨大，已经达到了千兆网卡的最高值。 于是我们查看Redis慢查询日志，发现某个KEY被频繁调用，而这个KEY存在较大的VALUE问题，从而导致了上述故障。
解决办法是修改业务逻辑，修改后解决问题。
2. 缓存雪崩
背景：某个时间点，业务监控到大量报警，链接时间增加，数据库CPU飙升。
我们的缓存数据交换逻辑图如下
经过排查，我们发现数据库CPU由于查询量激增而出现激增。 根据我们的数据交换逻辑，当客户端请求命中Redis时，会直接返回。 如果发生MISS，则会执行数据库查询。 当查询结果返回时，数据将被写回Redis。 数据库查询量激增而业务却没有激增，显然是一种反常现象。 我们还检查了Redis记录，发现所有查询都是MISS，并且在一定时间内出现了请求击穿的现象，从而导致了缓存雪崩。
以上证据表明Redis本身没有问题，问题只是代码逻辑出现异常。 于是检查业务代码，发现设置KEY过期时间时没有进行验证，导致所有KEY同时过期，然后所有请求都重定向到数据库，导致缓存雪崩。
有两种解决方案：
（1）缓存过期后，通过队列或者锁机制控制访问数据库和缓存的线程数量。 这也是一种简单的流量控制方法；
(2)在超时时间上添加验证标签，判断是否超时。 如果超时到期并交换数据，则 REDIS 活动超时更改为更改超时。
三，
背景：收到REDIS服务器磁盘空间不足的告警。
众所周知，Redis是一个内存数据库，数据缓存在内存中。 唯一涉及磁盘的是持久文件。 顺着思路，果然，存储持久化文件的磁盘已经接近水线，并且持久化文件的大小是占用内存大小的三倍。 官网是这样解释的，Redis命令用于异步执行AOF(FILE)文件重写操作。 重写会创建当前 AOF 文件的大小优化版本。 即使执行失败，也不会丢失任何数据，因为在执行成功之前旧的 AOF 文件不会被修改。
简单来说，Redis的AOF机制和MYSQL类似。 它会以一定的频率（NO、EVERY）将写入的命令写入日志文件，用于快速加载数据以及REDIS重启后恢复数据。 写入了重复的命令，导致持久文件大小与实际占用内存不匹配。 作用是合并重复的命令，以减少持久日志的大小，减少内存占用，快速恢复数据。 举个重写的例子。
解决方案：4版本之后提供了自动重写功能，大大改进了旧版本中使用计划任务实现重写的方式。 （1）该设置是当持久文件大小超过基准百分比时触发； (2)SIZE设置当前持久文件大小大于字节数后触发。
4.Redis监控
目前Redis监控方案大多采用遍历INFO结果的方式进行数据聚合和展示。 一些核心指标包括内存碎片率、总分配内存、峰值内存消耗、命中数、未命中数、连接用户数、接收连接总数、每秒执行命令数、阻塞用户数等。
实现具体值一般有两种方法：
(1)通过脚本获取值；
(2) 通过客户端连接获取值。
一般有两种显示方式：
(1)展示方式；
(2)通过JS页面显示。具体如下图
5. 总结
综上所述，以上就是Redis在互联网金融系统中的应用，包括集群选择、业务场景应用以及使用中遇到的一些问题。 同时，我们也在尝试将Redis技术应用到更多的场景，也在进行多机房架构下的Redis大规模二层组网，探索更多的实用领域。
作者：顾黄亮，十年技术老手，有研发和运维经验，懂基础设施、安全、中间件、数据库，专注于智能运维系统打造。 曾就职于航天晨光、上汽集团云计算中心，现任苏宁消费金融安全运维部总监。
如果您在阅读本文时有任何疑问或疑问，欢迎您点击阅读原文参与相关话题的问答活动。 本文作者将为您解答疑问，您也可以与更多同行交流。
下载twt社区客户端APP
