好吧 。我们就开发一个客户端 。然后督促全公司的研发用它来替换目前正在使用的客户端 。
在这个客户端里面 。我们植入了日志记录 。记录了代码对 Redis 的所有操作事件 。例如耗时、Key、Value 大小、网络断开等 。
我们将这些有问题的事件在后台进行收集 。由一个收集程序进行分析和处理 。同时取消了直接的 IP 端口连接方式 。通过一个配置中心分配 IP 地址和端口 。
当 Redis 发生问题并需要切换时 。直接在配置中心修改 。由配置中心推送新的配置到客户端 。这样就免去了 Redis 切换时需要业务员修改配置文件的麻烦 。
另外 。把 Redis 的命令操作分拆成两部分：
安全的命令 。对于安全的命令可以直接使用 。
不安全的命令 。对于不安全的命令需要分析和审批后才能打开 。这也是由配置中心控制的 。
这样就解决了研发人员使用 Redis 时的规范问题 。并且将 Redis 定位为缓存角色 。除非有特殊需求 。否则一律以缓存角色对待 。
最后 。对 Redis 的部署方式也进行了修改 。以前是 Keepalived 的方式 。现在换成了主从+哨兵的模式 。
另外 。我们自己实现了 Redis 的分片 。如果业务需要申请大容量的 Redis 数据库 。就会把 Redis 拆分成多片 。通过 Hash 算法均衡每片的大小 。这样的分片对应用层也是无感知的 。
当然重客户端方式不好 。并且我们要做的是缓存 。不仅仅是单单的 Redis 。于是我们会做一个 Redis 的 Proxy 。提供统一的入口点 。
Proxy 可以多份部署 。客户端无论连接的是哪个 Proxy 。都能取得完整的集群数据 。这样就基本完成了按场景选择不同的部署方式的问题 。
这样的一个 Proxy 也解决了多种开发语言的问题 。例如 。运维系统是使用 Python 开发的 。也需要用到 Redis 。就可以直接连 Proxy 。然后接入到统一的 Redis 体系中来 。
做客户端也好 。做 Proxy 也好 。不只是为代理请求而是为了统一的治理 Redis 缓存的使用 。不让乱象出现 。
让缓存在一个可管可控的场景下稳定的运维 。让开发者可以安全并肆无忌惮继续乱用 Redis 。但这个“乱”是被虚拟化的乱 。因为它的底层是可以治理的 。
系统架构图
文章插图
文章插图
当然以上这些改造都需要在不影响业务的情况下进行 。实现这个还是有不小的挑战 。特别是分片 。
将一个 Redis 拆分成多个 。还能让客户端正确找到所需要的 Key 。这需要非常小心 。因为稍有不慎 。内存的数据就全部消失了 。
【redis生产环境配置 redis timeout配置文件】在这段时间里 。我们开发了多种同步工具 。几乎把 Redis 的主从协议整个实现了一遍 。终于可以将 Redis 平滑过渡到新的模式上了 。
推荐阅读
- 被精神控制的人有哪些特征？
- 自助唱歌房怎么样？如何用手机点歌呢？
- 迷你世界微缩模型少女心家具,迷你世界和我的世界有什么不一样
- 毛利与净利的区别是什么？
- 为什么男朋友总是胡思乱想？
- 电脑测速软件哪个准 电脑检测网速的软件分享
- 抑郁症检查去普通医院可以挂精神内科吗？
- 20＋的女生第一次谈恋爱要注意什么？
- 傲天无痕的全部小说 傲天无痕好看的小说排行榜前十名