压倒数据库的最后一根稻草

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

我们开发的是一款视频监控类的软件，分为视频采集端跟观看端。采集端可以是专业摄像头，手机，无人机等各类智能设备，观看端一般是手机或者电脑。最基础的功能，就是视频观看，采集端实时采集图像，编码，传输，观看端进行点播服务。同时采集端可以监测视频画面的运动幅度，然后触发报警，并且会录制报警视频。我们的云存储服务就是将录制的报警视频上传到云端，并且在观看端提供查看功能 

2.0 石器时代

第一个版本叫2.0，至于为什么叫2.0，或许这只是一个代号而已。

整个系统的框架如下：

整个系统由客户端， web服务器， 数据库， 文件存储服务器构成。文件服务器使用的是亚马逊的S3，对于小公司来说，选择亚马逊比自建存储的成本要低得多。

对于数据库的影响：

2.0版本中，对于一个event在上传一个分片文件之后，就要向web服务器汇报一次。web服务器判断该event是否是第一次汇报，如果是在数据库插入一行新的表项；如果不是，则要更新之前插入的表项

entid作key, value保存event的详细信息。这样在查询时，先按照cid+日期+类型找到列表key，从里面读取一页的数据。然后再根据这一页的数据，去查询里面每个event的详细信息。这样在查询列表时就不要再访问数据库了。

浓缩视频，压倒数据库的最后一根稻草

3.0版本上线三个月之后，系统运行的还算良好，但是我们发现数据库表项在飞速膨胀。我们的云服务用户已经有几万个，每个采集端每天平均都要上传几十条视频，所以按照这种速度，单表记录很快就来到了将近1000w。在mysql上，1000万几乎就是单表记录上限了。搞web的兄弟发现这一趋势后，做了分表方案。按照采集端的cid尾数 即(0-9)，将event，file，以及映射表分成了10张表。虽然是解决了存储方面的问题，但是随着使用云服务的用户在不断增加，数据库的访问压力也在渐增。在3.0版本，我们新增了浓缩视频功能，就是就可以，没必要非得全部挤在0点这个时间。我们把上传的时间随机延长至0~5点之间任何一个时间点，保证用户在早上起来后能查看到即可。很快就出了更新版本，服务器的访问压力随即降了下来，服务也回归正常。但是还是有一种隐约的不安，因为用户还在快速增长，不知道哪一天服务器又会遇到类似的问题。

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