之前的业务因为调用量非常小, 所以开发人员在设计时直接将音频保存到数据库中的, 并运行了相当一段时间, 但是从我进入这个公司以后没多久, 该业务的调用量逐渐从几十万/天增加到4kw/天, 虽然在数据库的性能上没有遇到瓶颈,但是在数据库磁盘空间上遇到了严重的瓶颈, 最多的时候数据库中产生的数据超过200G/机房/天, 而且这此音频是需要对外提供访问的, 因此不能直接删除也不能备份后删除, 同时因为预算等方面的原因, 公司也不打算上存储. 所以我需要解决的问题是, 在满足业务需求的同时, 用尽可能廉价的方案无缝解决这个问题, 既能扩展又需要兼容以前的访问. 后来经过协商, 公司只提供1个月的数据对外访问, 但是1个月的数据也需要6T左右的硬盘, 而线上的数据库硬盘只有2T.
因为一些三方的mysql的分布式方案(比如alibaba的cobar, Amoeba等)很多是需要从一开始就已经这样架构了, 如果需要使用这样的架构来解决我当时所遇到的问题, 会很困难, 而且基本没有新的硬件投入也很难实现. 所以我们想了一个简化的分布式的mysql方案, 说明如下.
(shou55所在公司的数据库是按天分表的, 写入只在当天的表, 读取会涉及到最近30天的表)
因为业务上只需要对外提供30天的数据访问, 因此按时间将整个mysql分为3部分:
1级数据库保留最近10天的数据;
2级数据库保留10天到31天的数据, 第10天的数据是这两级数据库中都有的;
3级冷数据, 保留超过31天的数据, 只保留数据, 不提供访问.
再细化一下:
(1)在1级数据库上用计划任务将超过10天的数据传送到2级数据库, 并导入2级数据库, 导入成功以后清空1级数据库中刚才传输过去的这一天的数据
(2)在2级数据库上用计划任务将超过31天的数据传送到3级冷备份盘中, 成功以后清空这一张表
(3)上面2步已完成了数据的切分, 但是分完以后如何合起来对外在逻辑上作为一个整体提供访问了?
因为我司对外提供访问的url里包含了一个时间戳, 是精确到纳秒的19位的一个整数, 所以shou55使用nginx根据这个url中的时间戳字段来做路由, 以10天的时间戳为临界点, 大于这个临界点的就通过ng反向代理到使用新数据库的音频服务, 小于这个临界点的就代理到老的服务. 同时在ng服务器上再启一个计划任务, 每天定时更新ng配置文件中的这个临界点变量值即可. shou55使用的不是官方的nginx, 而是淘宝开源的tengine , 这样在如 > < 这样的整数比较上都非常方便.
经过上面几步, 一个特别简化的分布式mysql数据库就基本完成了, 只要3级冷备盘还有足够的空间, 1级和2级数据库就可以将空间不断的轮替. 这样只增加了几块硬盘以及增加了几个计划任务, 原来的程序上没有做任何的调整就满足了我司的需求. 同时也不得不说nginx在灵活性上面给我们提供的发挥空间真的很大.
阅读(1048) | 评论(0) | 转发(0) |
