微众银行Redis应用实践

胡盼盼老师在分析了Redis社区版的痛点后,介绍微众银行结合自身需求对其进行了改进,打造出基于开源Redis开发的分布式缓存平台WeRedis。然后以典型的金融场景为实例,详述WeRedis的集群规模、架构演讲,以及运维管理。

展开查看详情

1.微众银行Redis应用实践 演讲人:胡盼盼 全球敏捷运维峰会 广州站 1

2.概要 Redis与WeRedis WeRedis典型应用场景 WeRedis集群规模 WeRedis的架构演进 WeRedis运维管理 全球敏捷运维峰会 广州站 2

3.Redis社区版的痛点 • Redis 2.0社区版本 • 主从模式架构,依赖外部组件实现自动高可用 • 不能水平扩展 • 权限管理功能非常有限 • Redis Cluster社区版本 • 通过分片架构,实现了自动高可用和水平扩展功能 • 权限管理功能依然非常有限 • 资源统计和资源控制功能(多租户)非常有限 • 无法禁用某些指令 • 缺少统一的运维与管理平台 全球敏捷运维峰会 广州站 3

4. Redis与WeRedis observer stat proxy admin WeRedis是基于开源redis开发的分布式缓存平台,除拥有开源redis的特性外,还有如下特点: ✓ 多租户与细粒度的鉴权:WeRedis可以根据子系统进行鉴权。每个子系统通过不同的账号访问自己的数据 ✓ 资源控制:子系统进行资源控制,比如控制子系统的连接数、访问量、内存使用量、单次IO的大小等 ✓ 高危操作隔离:WeRedis屏蔽了高危的运维命令以及风险高的访问。 ✓ 扩展性更高:WeRedis支持多集群模式,可以通过在线扩容底层小集群达到更高的扩展性 ✓ 可用性更高:WeRedis的多集群跨IDC部署架构,当底层1个小集群故障时,不会影响整个集群的使用。 ✓ 智能分析与管控:WeRedis可以获取智能的分析报告。例如:按照子系统统计TPS、访问时间、访问成功率、占用 内存大小、大key预警等。 全球敏捷运维峰会 广州站 4

5. WeRedis典型应用场景 微粒贷/微众银行APP • 应用APP通过访问GNS获取客户ID对应的 RDCN号,优先访问redis,redis访问超时 ECIF GNS 则访问DB DB DB • 新客户需要访问ECIF插入客户数据 分布式核心应用 DCN1 DCN2 DCNX • 同时写redis和DB,异步对账程序核对数据 应用 应用 应用 (以DB为准) DB DB DB 全球敏捷运维峰会 广州站 5

6.WeRedis目前规模 3000+实例数 180+子系统接入 60+套集群 最大单集群容量 全行业务覆盖 WeRedis 1053G 全球敏捷运维峰会 广州站 6

7. WeRedis架构演进 – 1.0 Redis 2.0 patern 3 sentinels + 3 nodes System A 业务发展 System A System B 运维崩溃ORZ - 运维难度大,成本高 业务发展 业务发展 - 运维效率较低 System B System C - 可扩展性较差 业务发展 System D 全球敏捷运维峰会 广州站 7

8. WeRedis架构演进 – 2.0 Proxy - 权限控制(接入权限、命令权限) OB - 资源控制(流量、连接等) Accessing - 可扩展性高 proxy selection - 共享集群,成本降低 OB Observer -proxy可用性探测 -proxy流量隔离 OB -路由管理 Application via Redis protocol Observer Cluster 缺陷 -cluster主节点故障影响面大 Proxy Data location Redis Redis Redis shard1 shard2 shard3 Proxy Redis Redis Redis shard4 shard5 shard6 Proxy Proxy Cluster Redis Cluster (Storage) 全球敏捷运维峰会 广州站 8

9. WeRedis架构演进 – 3.0 OB Statistics metadata query OB OB WeRedis Statistics Observer Cluster Accessing proxy selection Proxy/Redis Cluster metrics report Proxy Cluster Cluster Cluster Application via Partition Partition Partition Redis protocol Data location … Proxy Redis Partition(Storage) Proxy Redis-Cluster Redis Redis Redis Proxy Cluster shard3 shard1 shard2 全球敏捷运维峰会 广州站 9

10.WeRedis架构演进 – 3.0特性 可用性高 扩展性高 资源控制 权限控制 •所有组件满足高可用 •负载均衡 •流量控制 •UM鉴权接入 •某个cluster集群故障, •性能和容量线性扩展 •连接数控制 •数据隔离 只影响部分业务 •在线缩扩容,对业务 •容量控制 •管理命令屏蔽 透明 •高风险操作屏蔽 全球敏捷运维峰会 广州站 10

11. WeRedis架构演进 – 典型架构案例 • 同城多中心,跨IDC部署 observer observer observer proxy proxy proxy proxy P0_S1_M P0_S1_S Cluster P0_S1_S P0_S2_S P0_S2_M Partition0 P0_S2_S P0_S3_S P0_S3_S P0_S3_M P1_S1_M P1_S1_S P1_S1_S Cluster P1_S2_S P1_S2_M P1_S2_S Partition1 P1_S3_S P1_S3_S P1_S3_M IDC1 IDC2 IDC3 IDC4 全球敏捷运维峰会 广州站 11

12. WeRedis架构演进 – 典型架构案例 • 同城不跨IDC部署(正常情况) observer observer observer observer observer observer proxy proxy proxy proxy proxy proxy P0_S1_M P0_S1_S P0_S1_S P0_S1_M P0_S1_S P0_S1_S P0_S2_S P0_S2_M P0_S2_S P0_S2_S P0_S2_M P0_S2_S P0_S3_S P0_S3_S P0_S3_M P0_S3_S P0_S3_S P0_S3_M Cluster Partition0 Cluster Partition0 P0_S1_M P0_S1_S P0_S1_S P0_S1_M P0_S1_S P0_S1_S P0_S2_S P0_S2_M P0_S2_S P0_S2_S P0_S2_M P0_S2_S P0_S3_S P0_S3_S P0_S3_M P0_S3_S P0_S3_S P0_S3_M Cluster Partition1 Cluster Partition1 全球敏捷运维峰会 广州站 12

13. WeRedis架构演进 – 典型架构案例 • 同城不跨IDC部署(集群异常) observer observer observer observer observer observer proxy proxy proxy proxy proxy proxy P0_S1_M P0_S1_S P0_S1_S P0_S1_M P0_S1_S P0_S1_S P0_S2_S P0_S2_M P0_S2_S P0_S2_S P0_S2_M P0_S2_S P0_S3_S P0_S3_S P0_S3_M P0_S3_S P0_S3_S P0_S3_M Cluster Partition0 Cluster Partition0 P0_S1_M P0_S1_S P0_S1_S P0_S1_M P0_S1_S P0_S1_S P0_S2_S P0_S2_M P0_S2_S P0_S2_S P0_S2_M P0_S2_S P0_S3_S P0_S3_S P0_S3_M P0_S3_S P0_S3_S P0_S3_M Cluster Partition1 Cluster Partition1 全球敏捷运维峰会 广州站 13

14.WeRedis运维管理-踩过的坑 性能问题 • 主机初始化配置:关闭SWAP • 主节点的RDB持久化关闭 • 大key高时间复杂度操作需要注意,TTL过期隐含del,4.0后用异步后台删除 高可用问题 • 主节点的持久化关闭掉后,不能配置自动启动。确认集群切换完成后才能启动,避免数据丢失 • 集群中多数主节点故障,集群不能自动切换,搭建时注意机器满足高可用。可以用cluster failover TAKEOVER 强制切换。 • 当拥有2个及以上从节点时,在主从切换时,注意cluster-migration-barrier参数设置,如果用默认值1,则可能 出现从节点的分布不符合预期。 容量问题 • 关注内存碎片率,在业务低峰期谨慎打开activedefrag回收内存碎片(redis4.0以后) • Redis软件make时,要用make MALLOC=jemalloc(默认),否则redis4.0之后的内存碎片回收功能不能使用 全球敏捷运维峰会 广州站 14

15.WeRedis运维管理-开发规范 1、系统在设计Key的时候必须以子系统ID为前缀 • 生产系统的key必须以“”systemid:”为前缀,否则访问集群将返回失败。仅独占集群的子系统可以通 过申请白名单(ITSM表单),绕过Key校验规则。 2、避免设计一个key过大 • 对member大于1000的key 或 memory大于 10M的key,将会出报表建议整改 3、限制单次操作key的长度 • 为了避免集群堵塞,单次操作Redis的Key长度限制为1K,数据长度限制为100K 4、Cache类型集群要求数据必须设置TTL为3天以内 • 为了避免垃圾数据堆积,会对Cache类型集群中没有设置TTL或者超过3天的key出报表建议整改 5、WeRedis的接入使用受到以下约束 • 不支持Redis原生的系统指令,如INFO、FLUSHDB、SHUTDOWN等; • 不支持Redis Cluster相关指令,如CLUSTER FAILOVER等; • 不支持KEYS指令、SCAN指令; • 不支持Redis原生的阻塞式指令,即BLPOP、BRPOP、BRPOPLPUSH; • 不支持订阅/发布操作,即SUBSCRIBE、PUBLISH等; 全球敏捷运维峰会 广州站 15

16.WeRedis运维管理-WeRedis Admin 监控 运维 • 各组件实时运行情况监控 • 集群搭建 • 历史数据对比 • 节点替换 • 容量预警 • 在线缩扩容 • 趋势分析 • 多租户资源控制 全球敏捷运维峰会 广州站 16

17.WeRedis运维管理-WeRedis Admin 全球敏捷运维峰会 广州站 17

18.WeRedis运维管理-WeRedis Admin 全球敏捷运维峰会 广州站 18

19.WeRedis运维管理-WeRedis Admin 全球敏捷运维峰会 广州站 19

20. THANK YOU! 全球敏捷运维峰会 广州站 20

数据连接未来!围绕Database、Bigdata、AiOps的企业级专业社群。行业大咖、技术干货,每天精品原创文章推送,每周线上技术分享,每月线下技术沙龙,受众20W+。