道友，日增量百万级业务该如何进行数据设计呢？

最近托更近一个月的左羊，被阅读过公众号的小伙伴找到帮忙对一个日增量百万级业务数据设计进行技术支持。哈哈哈，公众号运营了两年终于有小伙伴开始认可左羊了。十分荣幸，这让左羊有了继续将内容输出进行下去的信心，输出更高质量的内容反馈关注左羊的伙伴。本内容除去技术部分大多为虚构，如有雷同麻烦您改下~

背景

地点：盛京

时间：仙历2021年秋

人物：仙门镖局的黄掌柜，经常托更的左羊

Q&A

黄掌柜：Hi,左羊。我通过迷糊道人的介绍了解到您曾做过的一款名为"慧眼灵识分析系统"的产品。这个跟我们现在想做的“镖局乾坤袋识别业务”有些相似的点想跟您请教下。

左羊：十分荣幸能够得到您的认可，贵镖局这块目前有什么痛点？

黄掌柜：我们镖局现在的“镖局乾坤袋识别系统“预计在一批乾坤袋分拣线上使用，每天抓拍照片的数量按照30万张，每天的各种产生记录会有上百万条，数据存储和汇集这一块我们目前用的MySQL，但是现在只是一条分拣线上进行试运行，每天也就几万条数据问题不大，但是整个镖局铺开用的话我感觉就不够用了。

左羊：您的担忧是对的，这种数量级的数据贵镖局预计会存储多久呢？

黄掌柜：这个数据存储量我们没有估算过，取决于我们当家的能提供多少存储空间，我们预计存储三个月，您看这合理么？

左羊：这个确实需要看Boss的需求，如果按照储存三个月（90天）日增数据100万，三个月的数据会在9000万左右，可以推荐只将抓拍的记录存在数据库中然后按天水平分表，这样的话对查询性能不会有太大影响。

    当然我这里只是简单的提到了一些分库分表方案的设计，但是在进行具体的方案落地的时候，是需要数据库中间件技术的支持的。

    以Java体系为例，可以用ShardingJDBC去做这件事，您可以推荐贵镖局工程师研究下它的理念。也可以去研究业内常用的据库中间件技术，一般有 Sharding-Sphere 以及 MyCat 两种，用的公司多，技术方案成熟，贵镖局可以自行选择一个，去看看他们的官网，跑跑Demo。

黄掌柜：数据这块我大致明白您的意思，就是原本大块存储的数据就行分片存储，再通过数据库中间件技术去负载操作。那我们原本直接将图片数据存储到服务器磁盘中然后将绝对路径存入数据库，这个我也担心会有问题，这个该如何处理呢？

左羊：这个担忧也是对的，这么大量的图片数据不建议直接存入MySQL数据库或落到服务器磁盘中，可以先存入文件服务器中然后将存储路径存入数据库进行管理与展现（可选的有s3存储协议的Minio或分布式文件HDFS）。可能会出现磁盘不够用的情况，如果服务器资源不多的情况使用RAID磁盘阵列来处理，服务器充足的情况可以采用多台服务器分布式部署来处理。

黄掌柜：（liao）了解(le)了，在仙魔大战的时候，会有大量仙人通过我们镖局向前线邮寄乾坤袋。这个我担心MySQL扛不住这么大瞬间请求，该如何处理呢？

左羊：这个要看贵镖局需要的数据实时性高不高，首先在实时性不高的情况下可以采用将汇集上来数据先行存入消息队列中进行削峰，后面峰值过去在慢慢同步到数据库中。

左羊：如果实时性要求高服务器资源又不多的情况下，可以先将数据写入到Redis或MongoDB等高速读写的内存数据库中，它们的实时读写都可以达到万级设计良好的情况可以达到十万级，然后在凌晨或其他业务冷却时间段向数据库同步进行永久性存储。

黄掌柜：左羊，谢谢您哈，我先消化下今天Q&A的内容，后续有问题，我再请教您哈。

左羊：架构千万种，最符合的架构才是最好撒~