- 工程实践 - 《QPS百万级的有状态服务实践》01 - 存储选型实践

           本文属于专栏《构建工业级QPS百万级服务》

---

        《QPS百万级的无状态服务实践》已经完成。截止目前为止，支持需求“给系统传入两个日期，计算间隔有多少天”的QPS百万级服务架构已经完成。如图1：

  

图1

        可是这个架构不能满足需求“给系统传入两个日期和国家信息，计算中间有多少个节假日”，也不能满足需求“查到最近用户的历史查询记录”。

        首先每个国家，每年的节假日不一样。以中国为例，每年的五一的开始时间和结束时间，由国务院办公厅大约提前一年发布。所以我们的服务需要实时去更新节假日的信息。这时候第一个问题来了，数据如何更新。

        第一步是数据生产，由于国家很多，每个国家每年的节假日发放的网站和数据格式都可能变化，而这种更新频率不高，但又十分重要的数据，一般需要自动化生产+人工检测。先通过API或者爬虫爬取到信息，然后程序检测，程序检测有风险的人工介入。所以我们的架构升级为图2。

      

图2

       这里我们面临着第一个存储选型。那就是我们的节假日数据存在哪里。这里我们从数据量大小、写频率、读频率、数据生产成本、存储成本等几个角度，分析数据特征。

• 数据量大小：每个国家节假日不超过100个，一共195个国家，不超过20000个节假日，假设每个节假日key为30个字节的，时间信息为两个int32的值，那总的大小不超过5MB
• 写频率：一年的节假日一般在一年的某一天更新，加上更正，195个国家，365天，写频率大约是1次/天
• 读频率：这里取决于业务需求，如果我们希望新的节假日数据发布之后，我们可以在一分钟内更新，那我们读取数据数据频率大约是1次/分钟
• 数据生产成本：这里数据生产是依赖自动化程序+少量人工，整体来说成本偏低。所以即使数据丢失，重新生产也能接受。不过这可能会让服务小时级不能工作，所以数据备份也是需要的
• 存储成本：目前计算机资源，磁盘相对便宜，成本更高的是CPU和内存。所以存储在磁盘本身便宜，而存储中间件的成本，基本取决于需要读取数据的延迟和频率

        分析完数据特征，下一步要做的就是技术选型。技术选型，本质上做的事情是，找到满足业务需求的最便宜的方案（这里的便宜不止是机器资源，还是开发、维护成本）。从上面的业务特征，可以大概刻画出我们想要的存储中间件特征为，数据量不大（按数据量大小收费比较划算），写少读多（数据读取便宜，写可以贵点），数据生产成本不高，对业务小时级别影响（有备份，但也不要成本太高）

        这里我不会选择Redis，因为数据可以分钟级更新，10秒级的数据延迟服务都可以接受，那内存型的存储太贵了点。同理，我也不会选择Mysql，内存+磁盘型依然有些浪费。所以磁盘存储的对象存储系统更便宜，也能满足我的需求，以阿里云对象存储系统OSS为例，下图是我截取的核心收费价格

    

      

图3

        如图3，我的选择是同城冗余存储标准型。因为数据取回的频率很高，且不想接受小时级别服务停止。

        很明显，这里的架构“似乎”有优化的空间，比如只在数据变化时，服务容器才去获取数据。这样获取数据频率变低，这让我们可能可以考虑低频访问型。但是目前的业务形态，我不会去做这样的事，因为这个方案，需要“数据生产方通知+服务容器轮询”，它增加了服务的复杂度，而成本大概也只是从2分钱变成了1.5分钱。但是着不意味着，所有业务都不需要，比如数据从5MB，变成了5GB、5TB、甚至5PB，量变就引起了质变。现在我们先只考虑5MB，并且我们知道50MB以内，我们的方案都没有变的必要。不要过早的考虑优化，是架构设计的重要哲学之一。这里为了尽可能展示更多的功能，我会在后面的文章说明如何做到数据生产方通知，

        到目前为止，我们只解决了数据生产和存储的问题，数据更新的问题还没有解决。用户查询相关的问题也还没有开始考虑。这些我会在后续的《QPS百万级的有状态服务实践》系列中，分享我的经验。

---

        下一篇《QPS百万级的有状态服务实践》02 - 冷启动和热更新