3.0版本告一段落之后，随即开始了4.0版本的规划。4.0版本主要要解决的，就是服务器的访问压力，包括web服务器以及数据库。主要的性能瓶颈还在数据库上， web服务器作水平扩容很简单，因为在web服务器前面有nginx作为接入层做负载均衡，新增一台web服务器直接在nginx上加个配置就行了。但是数据库因为还没有做分库，所以只能先优化单台数据库的性能。使用Innodb引擎写性能每秒几百个，还能再撑一段时间。运行云存储服务的采集端大约有几万台，每秒钟的并发请求量还没那么大。但是数据量增长太快却是一个问题，虽然已经按照采集端的cid做了分表，但是表项的数据按照现在的增长速度很快又会到千万。分表也不可能这样无限制的做下去，但是分表策略却是可以调整的。其实我们的云服务有一个特点，就是数据只保存30天，查询的时候也是按天来查询，所以优先应该选择按天来分表才对。30天过后，直接删除掉老的表项，这样数据就不会无限量的膨胀。每天建一张表，数据量也不会达到单表上限。仅仅是这样实现一下其实也不复杂，但是考虑到版本兼容就没那么简单了。数据库还是只有一台，用户如果还是使用3.0的版本，我们也得按照新的分表方式来写表。这样就带来一个问题，即按时间分表，到底是按照event的触发时间来分表，还是按照event的上传时间来分表？这到底有什么区别呢。一般情况下，采集端在触发报警时，要立马上传视频。但是如果当时断网了，我们也会缓存在本地，等到网络恢复了再上传。所以有可能在当天触发的报警视频在第二天才能上传，也有可能更晚。刚开始想按照event的上传时间来做分表，这样做只要在服务器端判断下当前时间，将请求直接插入到对应日期的表项中就行了。但是这种做法，查询性能就比较差了。查询的时候按日期查询，这个日期是event的触发时间。我们并不能确切地知道这一天的报警视频到底被存储在哪些表项当中。只能遍历这一天的前后几张表，都查询一遍。很显然这会影响到查询性能。于是就考虑按照event的触发时间来做分表。但是又有另外一个问题，每个event在刚开始上传时，需要向web服务器汇报一次event信息，结束时要再汇报一次，更新event的上传状态和总时长。在开始汇报时，带了event的触发时间信息，但是在结束汇报时并没有带时间信息，只有event id。因为在3.0版本中，是根据cid来分表的，在结束汇报时带了cid信息。但是按照4.0版本的分表方式，老版本的采集端在结束时汇报，紧靠cid信息就不知道到哪张表里去更新了。简单的方法就是从当天的表项，往前遍历，直到查到为止。但是这样效率就很低了，更新一次带来的性能压力太大。后来想到了利用redis缓存,其实在event第一次汇报信息时，我们就已经将这些信息记录在redis里面了，所以只要根据eventid 在redis里面查到event的触发时间，然后就可以直接插入到数据库中。这是为了兼容3.0版本的策略，但是在4.0版本中，我们直接在申请eventid时，就带上了日期信息，保证获取到的eventid的前面几位就是event的触发时间日期。这样根据eventid就可以知道分表信息了，省略了查询缓存的过程。4.0版本的优化大概就是这样了。但是这还远未结束，仅仅的分表策略终究是有它的极限的，单台数据库的读写性能就摆在那里，下一步要做分库才行。为了提高性能，还可以使用异步化写入，即数据先保存到缓存中，然后批量写数据库，降低数据库的峰值压力。

总结：

很多时候， 我们谈到高并发 高负载，就会想到集群 ，分布式等一些高大上的名词。但是如果连单机性能都没有做好，谈那些也就是空中楼阁了。记得之前看到，说访问量排名全世界前20的网站stackoverflow,只有区区20多台服务器，而且用的是.net。可见对业务本身的优化，比基础设施的建设更加重要。业务优化应该达到两个目的：第一，使你的代码运行性能更高；第二，使得整体的业务架构易于扩展。谈集群，分布式部署，也不是一蹴而就。在开发代码时，就要考虑到能够水平扩展等因素。这样在未来，扩展集群时，便也轻松了许多