图中(图片省略)展示的是截止2015-02-04 18:00 流量表的数据量(LL统计)， 大为吃惊 汗！！！（加上逗号来看看 126,849,121）
1、数据量意味着钱，当然值得高兴
2、之前也一直在说，Portal的访问很慢（MySQL的单表达到1亿能不慢嘛）
3、我们在做分布式的数据库，将SQL中的计算移到Java中，然后Portal也可以部署多个来分担计算的压力
（Portal的分布式通过Tengine的静态Session插件【session_sticky】来实现）
（Tengine的分布式通过软负载【LVS】来实现）
4、我们来算下五分钟的数据量，126849121/8(月)/30(天)/24(小时)/12(分钟)≈1835.2
根据MLJ统计，以及现网数据的统计，平均可归并的比率大概在10左右（大客户的值要高），就是说10条数据经过触发器归并后剩下一条。原来1.2亿的数据就剩下1268万了，
然后还要经过分布式数据库去散列下，（假如部署了20台MySQL），每个库中单表的数据量就剩下63万了（散列均匀的情况下）。
5、根据上面的统计，在现有业务量不增长的情况下，CDN Portal的第二代架构支撑接下来的一年是完全没有任何问题的。
实际情况应该没有这么乐观，比如业务量增长10倍，单表数据量就会接近千万级别了（又是一个瓶颈所在）。
6、据说，年前不会上线CDN Portal的第二代架构版本。保守估计30天后上线，这30天数据量就会增加1585万。
so。。。建议现网做下数据切割，将3个月之前的数据移走。
7、既然数据归并可以降低10倍的数据量，那么大数据HotDegree做数据归并也是迫在眉睫。
8、作为第三代架构的前期调研：
目标：
8.1，Portal的数据延迟由目前的30分钟降低到10分钟（实时展现谁不想呢）
8.2，一定程度上实现真正意义上的分布式（随意添加机器，减少机器）（说的容易，做起来 咳咳）
8.3，HotDegree的资源和Portal的资源整合（collect 请走开）
8.4，在MySQL上做分库分表依赖现有开源软件（目前采用的是Cobar），虽然Cobar能满足现有场景下的需求，
但缺点也很多，另有一款牛叉的开源软件TDDL（开源不完整）。
所以，第三代架构更多的考虑是Hadoop+Zookeeper+HBase+Phoenix+Spark（研发力量必须强）
8.5、页面加载时间保持在3s内（这才是客户最满意的地方）
8.6、第二代架构中的缓存暂没有加入，这里会成为必需品，而且不采用堆内缓存（考虑 redis、etcd）
8.7、对一个应用连接多个库说No（引入消息中间件）
8.8、现有的RPC改造升级（引入服务注册等）
8.9、自研分布式Session管理软件（服务高可用性必备）
8.10、要走的路，要踩得坑还有很多（慢慢来）
现场的事儿：
1、MySQL需要进行调优（这个对查询的影响真的很大）
2、数据的可用性问题，MySQL主备配置（万一出账的那一刻，一台MySQL挂了，钱就少了）
3、了解第三代架构采用的技术知识（维护必备）
4、监控先行。。
5、