腾讯微博广告平台--监控系统的开发与总结

    从13年7月份开始，就一直呆在微博部门进行效果广告的后台配套系统的开发，很荣幸，做为一位实习生，能真正的参与到项目中去，仍是颇有收获的，有必要把这几个月本身所作的事稍微总结一下，理清一下思路。

可能有些东西涉及到公司隐私，因此我不会详细的去描述。此随笔仅供各位看官学习交流之用，请勿转载，请勿用于其它目的，如引发纠纷，请本身负责。

    言归正传，我刚到部门的时候，微博正在进行商业化，刚经历了几个月的封闭开发，广告平台已经大致成型，可是缺乏一些对广告效果的监控。个人工做主要是负责这个。  

    技术上，其实说白了，就是对数据库的增删改查（并且通常只涉及到查）。那这么说，就更加简单了，查数据库——整理数据——前台显示。是的主体就是这么三步。其实就是通俗意义上的信息系统。

   接下来，说说咱们刚开始碰到的问题，随着系统的开发，查询条件愈来愈复杂，须要显示的数据也愈来愈多，产品和运维的人但愿全面详细的了解整个平台每小时，天天，每月的各个终端等等详细状况，还须要了解某些个订单，广告主的实时广告消耗状况等等。伴随着系统功能的不断增长，某些查询也愈来愈耗时了，并且当你有不少的查询语句，并且查询时间愈来愈长，会对线上的系统的稳定性产生影响，固然能够有从库，加索引等等优化查询语句的办法，在必定程度上能够提升数据库响应时间，可是终究不是一个长久之计。

  另外一方面，刚开始设计数据库的时候，咱们尽可能知足第三范式，考虑节约内存，节约数据传输大小，实时响应等等各方面，可是碰到查询的时候，就会带来一些问题，有时候为了查询一个广告主的全部订单，你可能要经过先查询广告主的全部计划，而后从计划表中获取全部的订单，而后再去订单表中查询具体的订单信息，这种查询语句，想必你们看起来都会嫌恶心的，固然能够用join，可是合适么，我是不太看好这种方式的，尤为是还涉及到数据库的量，速度，各类事务等等。固然是我的习惯问题，我比较喜欢干干净净的sql语句，不崇尚特别复杂的SQL语句，也不崇尚特别复杂的代码，好的代码必然是很是清晰的，仅仅是我的理解。

   从上面两方面，本来是一个为了查询的“附赠”系统，却要开始改变整个广告系统主体了，固然这也是很是有必要的，起码组长也是很是认同的，那说说咱们具体是怎么改变上面这些矛盾的，上面的那些个矛盾可能也不全。

    1. 修改部分原有的数据库表，多增长一些冗余字段，我只是查的功能，那这就须要增“删”修这三方面都作一些改变。并且从这个项目中也能够体会到，数据库表的设计，第三范式不必定是最好的，有时候作一些冗余，会带来不少的方便。

    2. 针对产品，运维等相关人员提出的各类数据要求，新增一个数据库，专门作统计需求，将计费，广告等信息经过php脚本，同步到新的统计库中，并在统计库原始表的基础上，增长各类脚本，作统计，造成各个统计表。凡是作过数据统计的人应该都知道，开发人员最讨厌的就是统计数据，由于这个数据的东西，它是不容许有错误的，数据哪怕有一点不对，就得查问题。

    3 在新建了统计库的基础上，咱们有不少的脚本在周期性的作着统计工做，这里得保证各个脚本正常的运行，数据的正确，当前系统定时运行的脚本可能已经有20多个了。能够理解为从两个源头流出的数据通过一个个管道到达了一个个表，并且从某一方面来讲，监控系统，也必须带有一些监测的功能，而最好的反应系统运行状况，就是各类数据，一旦数据出了什么问题，咱们可否立刻查到问题的所在。这里引出了，咱们是如何解决这些的。首先，说一些常识性的东西，随着脚本的增多，脚本的命名，各个脚本的分类，放在各自的文件夹当中，各个脚本运行都须要在一些关键的点上打日志，脚本运行其实涉及到两种，正常运行和数据恢复，每一个系统或多或少会有一些bug，我这边的数据算是最底层的数据了，一旦个人前面有一些异常，就直接影响到了我这边的数据，因此有些时候，就会涉及到数据恢复，那伴随着脚本的增多，像这种从源头数据就已经有问题，我就须要运行N个脚本，并且是有必定的顺序，来恢复数据，这里就须要在编写每一个脚本的时候，考虑是否是还须要再编写一个错误数据恢复的脚本，这样脚本的量一会儿有翻倍了，固然有些脚本，没办法，就得用两个脚本，可是有的脚本，实际上是能够用一个脚原本实现的，只须要输入一些参数控制好了。另外，又新增了一个脚本控制中心，这个root型的脚本就是用来控制和运行全部的脚本的，若是咱们要数据恢复，只须要运行这个脚本，输入相应的控制参数，好了，它会本身去恢复的，而后咱们再校对一下数据就ok了。

    4 脚本的监控，数据的监控是不可避免的，这里实际上是两个需求，一个是脚本是不是正常运行了，另外一个方面是数据是否符合预期。脚本的是否正常运行，只须要读取待同步的表和同步的表，看看数据是否一致就能够了。可是若是要对每一个表都作这样的操做，就显得有点多余了，并且在能省查询语句就省的原则上，我是采用了从原始表，到末端表数据进行一致性判断，若是一致，那就代表这一条数据流上，脚本运行正确，数据没有问题，如若否则，它会告警，而后我就会去查各个脚本运行的log，固然新部署一个脚本，确定会多作一些一致性判断，到后来基本稳定以后，就不必了。经过这种方面，能最少的查询，判断数据是否有问题。另外，咱们采用了两个数据来源，两个数据来源数据通常状况下不会出现太大的偏差，其实一个数据来源是计费数据，另外一个是日志数据，计费数据只须要关注扣的钱（固然确定不只仅只有这个）就好了，日志数据就会含有一些其余的详细信息，那咱们就会将这两个数据来源的数据进行比较（至关于对原始数据的比较），偏差过大就开始告警，告警这一模块，就利用一些微信，邮箱接口等等。

    5. 经过以上的几部，如今基本上造成了一个闭环，重新业务上线，产生数据，数据分析，数据监控等等。并且对于咱们查找问题也给出了很大的参考性，举个例子，若是发现数据异常了，而我这边没有收到脚本同步之间的告警，那么能够直接跳过我这边的检查，在根据两个数据来源的比较，和往期数据的比较，发现日志上数据不对，查找是谁新上了东西么？作了哪些修改，哪些数据不正常，而不是像无头苍蝇同样从头开始查问题，能够很快发现问题，很快定位问题。经过上面的脚本跑统计数据，也知足了产品各项查询数据要求，扩展性还能够，固然确定还会有更好的作法，可是目前这是个不错的设计。

      差很少从宏观角度来说的就这些了，若是涉及到技术，倒反没有什么了，都是mysql+php+js+html,也没有涉及到很复杂的算法，很高深的技术，能解决问题的不必定是高深的技术，并且针对不一样问题的不一样思路。