、快速响应和高并发。为此，阿里云数加团队在结合多年应用经验的基础上，推出了分析型数据库。
什么是分析型数据库？
分析型数据库（Analytic DB，原名ADS），是阿里巴巴自主研发的海量数据实时高并发在线分析（Realtime ...
浏览：2633
就意味着系统可以具有非常高的性能。
四高并发优化
1. 逐级分流
1) 客户端缓存
我们的营销活动都是通过H5来承接的，app通过webview来加载或者直接通过浏览器加载数据时，可以利用浏览器缓存或者手机SD卡，将数据缓存在客户端，例如图片 ...
大数据量、高并发数据库的高性能、高可用性解决方案：
1.拆表：大表拆小表（垂直拆，水平拆；分表，分区partition，分片sharding），可以在应用层实现，也可以在数据库层面实现一部分；提高系统性能。
2.分库：把表放到不同 ...
ConcurrentHashMap可以这么快？并发读写缓存实现机制(二)：高并发下数据写入与过期并发读写缓存实现机制(三)：API封装和简化
1.高效的数据写入(put)
& & 在研究写入机制之前，我们先来回顾下上一节的内容 ...
浏览：2483
这个问题后我们修改了这部分程序代码，在读完数据后sleep几秒后再重新scan。 在修改完hbase的配置并且加上读Hqueue的scan频率控制后，Pora2情况明显好转，但处理累积数据时的速度还是不够快。 超大并发下的hbase问题 从统计指标上 ...
mysql做不了这样的逻辑处理。
我的解决办法：根据来访用户的session写入一个标记，如果有标记则不进行下面的数据库操作，但是还是不能挡住重复数据的出现。
请教大家有没有其他的办法解决我遇到的问题？（消息队列做这个可以吗？如果不用消息队列用Redis做标记（逻辑类似上面的session）的话是否可行？再高并发的情况下Redis是否也会出现类似MySQL的情况）
程序伪代码：
// 读取账户信息，并且余额加100
Account account = findAccount();
account.setBalance(account.getBalance() + 100);
updateAccount(account);
这段程序在多台机器上部署，如果保证数据的准确性。需要借助什么中间件? ...
、环境、时间 等，会高并发的入库操作。
2、离线分析，我们往往会对历史数据进行较高的并发分析，分析完成后。要么在线直接写入集群，要么离线导入集群中。
3、在线的风控平台 在交易发生时，会实时查询交易相关的数据，并且实时判断此笔交易的安全系数，如果有较高风险 ...
已由本人徽沪一郎在CSDN中通过&使用Spark+Cassandra打造高性能数据分析平台&发表。
&二&CassandraRDD高并发数据读取实现剖析
本文就 spark ...
浏览：2082
同时插入100条记录的话，如何保证并发插入的时候，不会插入失败 & &或者会锁住表呢，保证数据的顺利插入？ 3、由于每30分钟的定时统计分析也是要基于这个PV基础表进行Select查询操作，可能会建索引在该表上，但是Insert频繁肯定 ...
可是非同一般啊。
什么是系统的幂等性
幂等是数据中得一个概念，表示N次变换和1次变换的结果相同。
高并发的系统如何保证幂等性
查询的API，可以说是天然的幂等性，因为你查询一次和查询两次，对于系统来讲，没有任何 ...
浏览：2028
不用锁表，没有异常：在高并发网络中高效的更新数据库数据的方式
@font-face
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div ...
高并发之Memcached实战第10课-&Memcached Get获取数据&部分代码分享
先写个要存的数据的相关类：
public class Student ...
在高并发情况下，会遇到一种问题： 假设数据表中有一条记录为` id=123456; useCount=999`
a与b两个连接并发查询这个`id 123456`都执行下列sql:
`select * from table where id ...
我有一个product表数据, 它会产生10个coupon, 我在product表的字段里存了coupon_count的字段为10, 如果抢红包的话根据coupon_count的剩余数来生成红包（抢红包coupon_count 减一）。
当1秒内并发上 ...
前端请求php写入数据的接口太频繁，导致mysql中出现大量重复数据，如何处理 ...
将同时推出&高并发之Redis初级&&高并发之Redis高级&&高并发之Memcached实战&系列课程，敬请关注，谢谢 ...
能同时看到有票，显然会牺牲性能，在高并发网站中是不可取的。使用hibernate后我们提出了另外一个概念：乐观锁、悲观锁（即传统的物理锁）；
采用乐观锁即可解决此问题。乐观锁意思是不锁定表的情况下，利用业务的控制来解决并发问题，这样即保证数据的并发可读性 ...
浏览：8812
联网场景下数以百万的设备上千万级数据采集点每秒都在产生时序数据，这些海量时序数据是企业最宝贵的财富，能够帮助企业实时关注数据业务趋势，进行决策分析，监控设备性能和运行情况，帮助企业创造价值；但是业务高并发写入压力，海量数据存储成本，以及低效查询分析能力让传统 ...
共有19349页
你可能感兴趣新手园地& & & 硬件问题Linux系统管理Linux网络问题Linux环境编程Linux桌面系统国产LinuxBSD& & & BSD文档中心AIX& & & 新手入门& & & AIX文档中心& & & 资源下载& & & Power高级应用& & & IBM存储AS400Solaris& & & Solaris文档中心HP-UX& & & HP文档中心SCO UNIX& & & SCO文档中心互操作专区IRIXTru64 UNIXMac OS X门户网站运维集群和高可用服务器应用监控和防护虚拟化技术架构设计行业应用和管理服务器及硬件技术& & & 服务器资源下载云计算& & & 云计算文档中心& & & 云计算业界& & & 云计算资源下载存储备份& & & 存储文档中心& & & 存储业界& & & 存储资源下载& & & Symantec技术交流区安全技术网络技术& & & 网络技术文档中心C/C++& & & GUI编程& & & Functional编程内核源码& & & 内核问题移动开发& & & 移动开发技术资料ShellPerlJava& & & Java文档中心PHP& & & php文档中心Python& & & Python文档中心RubyCPU与编译器嵌入式开发驱动开发Web开发VoIP开发技术MySQL& & & MySQL文档中心SybaseOraclePostgreSQLDB2Informix数据仓库与数据挖掘NoSQL技术IT业界新闻与评论IT职业生涯& & & 猎头招聘IT图书与评论& & & CU技术图书大系& & & Linux书友会二手交易下载共享Linux文档专区IT培训与认证& & & 培训交流& & & 认证培训清茶斋投资理财运动地带快乐数码摄影& & & 摄影器材& & & 摄影比赛专区IT爱车族旅游天下站务交流版主会议室博客SNS站务交流区CU活动专区& & & Power活动专区& & & 拍卖交流区频道交流区
白手起家, 积分 25, 距离下一级还需 175 积分
论坛徽章:0
古老的服务器(99年的，cpu不详，内存256m)，古老的数据库正版SQL Server 7.0)。要跑5000万以上的数据(并且以每月上百万条的速度增加)，做即席查询。不知各位觉得跑的动吗？用户不肯花钱升级数据库到SQL Server 2000，但有可能升级服务器。如果还是用sql7的话，服务器要升级到什么程度才能跑得动？
小富即安, 积分 3478, 距离下一级还需 1522 积分
论坛徽章:0
如果硬件条件可以，SQL7是没多大问题的！另外考虑数据库的分流，历史数据和本年数据最好分开
小富即安, 积分 2670, 距离下一级还需 2330 积分
论坛徽章:0
应该没问题，如ccwlm741212所说。象上海很多一甲医院如瑞金医院，银行如农业银行也是用的是sqlserver7后台，对于前台和后台算法、冗余、历史数据、灾难拯救等软件因素都是要考虑好的。服务器的要求取决于客户端的连接数，实时处理的数据量，raid的选择等，这个问你们公司的系统分析员，他应该最清楚根据条件采取什么公司什么配置的服务器。
丰衣足食, 积分 528, 距离下一级还需 472 积分
论坛徽章:0
农行的总行也用sqlserver7吗？瑞金医院的数据量估计一年也就在2G左右，用上3年就够呛。
我觉得够呛，大的查询并发多了，肯定要等待很久。
其实，sqlserver7本身的性能还是不错的，就是不知道你的客户愿意升级到什么样的硬件配置
丰衣足食, 积分 528, 距离下一级还需 472 积分
论坛徽章:0
我们这里用6.5，单表没有超过100万条的，几十万条的表一共有10张左右
硬件：双至强900，1G内存，6个20G硬盘做RAID5
平时运行还算比较正常，就是查询比较慢，大查询要等上10秒以上
小富即安, 积分 2670, 距离下一级还需 2330 积分
论坛徽章:0
最初由 wangyuzhen 发布
[B]农行的总行也用sqlserver7吗？瑞金医院的数据量估计一年也就在2G左右，用上3年就够呛。
我觉得够呛，大的查询并发多了，肯定要等待很久。
其实，sqlserver7本身的性能还是不错的，就是不知道你的客户愿意升级到什么样的硬件配置 [/B]
我没说是总行啊。实际上，不可否认国内很多大公司用的后台是sqlserver7，这个版本的市场占有率是非常高的。一方面是成本的问题，一方面也是microsoft的NT系列操作系统的普及，一方面是操作者的素质（说到底还是成本），等等，就我所知道，上海医院后台基本上用的是sqlserver。还有很多企业、单位和机关也用的是sqlserver。
你说的查询问题，很大的程度依赖于前台开发工具算法的优化和技巧，控件和对象等的灵活应用；以及sqlserver语句的优化和表、索引、视图、完整性和规则合理设计以及历史数据的处理等，当然硬件也很重要。常用的实时查询要等待超过10秒，在硬件合理的情况下，就要考虑以上所说的软件因素，必要时做数据仓库。当然对于决策分析，一定的时间等待是可以忍受的。
呵呵，个人观点。
丰衣足食, 积分 528, 距离下一级还需 472 积分
论坛徽章:0
请问一下，为什么有的查询会一下子把临时表空间占满造成数据库宕机
丰衣足食, 积分 528, 距离下一级还需 472 积分
论坛徽章:0
请个DBA觉得不划算，养个DBA觉得划不来，很多单位也就招个三脚猫对付一下
在加上ms的东西入门太简单，让我们以为自己能搞定它
再加上数据量少的时候性能问题根本就不存在，等到数据量大了，有些问题也就不是那么好改了。
北京盛拓优讯信息技术有限公司. 版权所有 京ICP备号 北京市公安局海淀分局网监中心备案编号：22
广播电视节目制作经营许可证(京) 字第1234号
中国互联网协会会员&&联系我们：
感谢所有关心和支持过ChinaUnix的朋友们
转载本站内容请注明原作者名及出处大数据高并发系统架构解决千万上亿请求
我的图书馆
大数据高并发系统架构解决千万上亿请求
微信——腾讯战略级产品，创造增速记录，10个月5000万手机用户，433天之内完成用户数从零到一亿的增长过程，千万级用户同时在线，摇一摇每天次数过亿……在技术架构上，微信是如何做到的?日前，在腾讯大讲堂在中山大学校园宣讲活动上，腾讯广研助理总经理、微信技术总监周颢在两小时的演讲中揭开了微信背后的秘密。
周颢，2001年毕业于华南理工大学，计算机专业硕士。2005年加入腾讯广州研发部，历任QQ邮箱架构师，广研技术总监，T4技术专家，微信中心助理总经理。
周颢把微信的成功归结于腾讯式的“三位一体”策略：即产品精准、项目敏捷、技术支撑。微信的成功是在三个方面的结合比较好，能够超出绝大多数同行或对手，使得微信走到比较前的位置。所谓产品精准，通俗的讲就是在恰当的时机做了恰当的事，推出了重量级功能，在合适的时间以最符合大家需求的方式推出去。他认为在整个微信的成功中，产品精准占了很大一部分权重。
敏捷是一种态度，敏捷就是试错
微信研发团队里鼓励一种试错的信仰：他们坚信，在互联网开发里，如果能够有一个团队在更短的时间内尝试了更多机会（并能改进过来），就能有（更多的）机会胜出。敏捷是一种态度，在软件开发过程中，项目管理者都会非常忌讳“变更”这个词，但是在微信的项目运作中是不可以的。因为微信必须要容忍说哪怕在发布前的十分钟，也要允许他变更。这是非常大的挑战，因为打破了所有传统项目开发的常识。所有人都说不可能做到的，但微信做到了。研发团队所做的一切都是要给产品决策者有最大的自由度，而这个决策正是微信能够胜出的关键。
海量系统上的敏捷，无异于悬崖边的跳舞
敏捷有很多困境，如果做一个单机版程序，是可以做到很敏捷的，但是腾讯正在运作的是一个海量系统，有千万级用户同时在线，在一个单独的功能上每天有百亿级的访问，同时还要保证99.95%的可用性。在海量系统上应对项目开发会有很严谨的规范，都说要尽可能少的变化，因为90%-95%的错误都是在变更中产生的，如果系统一直不变更会获得非常高的稳定度，但是微信就是要在悬崖边跳舞。微信的研发团队要做一些事情，让敏捷开发变得更简单。
如何做到这一切？周颢认为，首先，必须建立起一种狂热的技术信念，就是一定是可以做到的。然后，需要用一些稳固的技术（理念）来支撑，例如大系统小做、让一切可扩展、必须有基础组件、轻松上线（灰度、灰度、再灰度，精细监控，迅速响应）……等等来支撑。
四大法器：大系统小做、让一切可扩展、要有基础组件、轻松上线
大系统小做
当设计庞大系统的时候，应该尽量分割成更小的颗粒，使得项目之间的影响是最小的。一切可扩展：在高稳定度、高性能的系统中间，为了稳定性能把它设计成不变化的系统，但为了支持敏捷需要让一切的东西都要变得可以扩展。必须建立基础组件：要解决复杂问题的时候，需要将已有的经验固化下来，固化下来的东西会成为系统中的一部分。轻松上线：当做了变化并把它从开发环境中部署到现有的运营环境中去，在这个过程中，“灰度”这个词非常关键，就是在黑和白之间的选择，必须要变成一种小规模尝试，再逐步扩展到海量过程中的一个问题。
大系统小做——
仅仅把模块变得更为清晰，这在海量系统设计开发中是不够的，还需要在物理环境上进行分离部署，出现问题的时候可以快速发现，并且在最快的情况下解决掉。
大系统小做，混搭模式
将不同的应用逻辑物理分割独立出来，用户注册登录、LBS逻辑、摇一摇逻辑、漂流瓶逻辑、消息逻辑独立开来。把关键的逻辑混搭在一起，当所有的逻辑部署在同一个服务器上，确实也会带来很大敏捷上的好处，因为不需要额外的考虑部署和监控的问题。在整个微信的逻辑中，可能现在已经有上百种不同的逻辑，因为会在逻辑的分割上拆分成8-10种做分离部署。
一切可扩展——网络协议可扩展、数据存储可扩展
扩展的关键点有两块。一个是网络协议需要扩展，当要升级一个新功能的时候，会有一些比较大的困难，所以所有协议设计都比较向前兼容，但是向前兼容还是不够的，因为网络协议设计本身有非常多的功能也会有比较大的字段，相关的代码可能会有数千行，这一块不能通过手写方式完成。可以通过XML描述，再通过工具自动生成所有的代码，这是微信获得快速开发的一个重要的点。
另外一块就是在数据存储方面是必须可扩展的。在2005年绝大多数海量系统的设计都是采用固定字段的存储，但是在现代系统中会意识到这个问题，会采用KV或者TLV的方式，微信也做了不同的设计。
把复杂逻辑都固化下来，成为基础软件
在微信后台会有几种不同的基础组件，大致包括：
Svrkit——Client/Server自动代码生成框架:10分钟搭建内部服务器
LogicServer——逻辑容器：随时添加新逻辑
OssAgent——监控/统计框架：所见即所得的监控
报表存储组件——屏蔽容灾/扩容等复杂问题
灰度、灰度、再灰度
在变更后的部署方式上，微信在一些规则会限定不能一次把所有的逻辑变更上去，每一次变更一小点观察到每一个环节没有问题的时候，才能布局到全网上去。微信后台每一天可以支撑超过20个后台变更，在业界来说，通常做到5个已经是比较快了，但是微信可以做到快4倍。
腾讯内部的上线系统
而所谓灰度发布，是指在黑与白之间，能够平滑过渡的一种发布方式。AB test就是一种灰度发布方式，让一部用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。（在腾讯，灰度发布是最常采用的发布方式之一）
孙子兵法：古之所谓善战者，胜于易胜者也
常识上，解决一个复杂问题的时候，会用高明的技巧解决复杂的问题，这个不是微信团队的目标，他们追求的要做到让所有问题很自然和简单的方式解决掉。在周颢看来，微信架构的技术复杂点在四个要点：协议、容灾、轻重、监控。
协议：手机终端跟后台服务器之间的交互协议，这个协议的设计是整个系统的骨架，在这一点做好设计可以使得系统的复杂度大大降低。
容灾：当系统出现了若干服务器或若干支架（宕机的时候），仍然需要让系统尽可能的提供正常的服务。
轻重：如何在系统架构中分布功能，在哪一个点实现哪一个功能，代表系统中间的功能配置。
监控：为系统提供一个智能仪表盘。
在协议设计上，移动互联网和常规互联网有很大的区别。首先有CMWAP和CMNET的不同，在中国现在有相当多的手机用户使用WMWAP连接，还有就是在线和离线的概念，当QQ下线的时候叫离线，当你登录的时候叫在线。但是在移动互联网这两个概念比较模糊。从微信的设计中，不管在线还是离线系统表现都应该是一致的。
还有一个是连接不稳定的问题，由于手机信号强弱的变化，当时信号很好，5秒钟走到信号不好的地区，连接就必须断掉。这个中间带来不稳定的因素为协议设计带来较大困难。此外就是资费敏感的问题，因为移动互联网是按照流量计费的，这个计费会使得在协议设计中如何最小化传输的问题。最后就是高延迟的问题。
对此，业界标准的解决方案：Messaging And Presence Protocol：1)XMPP，2)SIP/SIMPLE。它的优点是简单，大量开源实现。而缺点同样明显：1)流量大：状态初始化，2)消息不可靠。
微信在系统中做了特殊设计，叫SYNC协议，是参考Activesyec来实现的。特点首先是基于状态同步的协议，假定说收发消息本身是状态同步的过程，假定终端和服务器状态已经被迟了，在服务器端收到最新的消息，当客户端、终端向服务器对接的时候，收取消息的过程实际上可以简单的归纳为状态同步的过程，收消息以及收取你好友状态更新都是相同的。在这样的模式之下，我们会也许会把交互的模式统一化，只需要推送一个消息到达的通知就可以了，终端收到这个通知就来做消息的同步。在这样的简化模式之下，安卓和塞班都可以得到统一。这样的系统本身的实现是更为复杂的，但是获得很多额外的好处。
让剩下系统实现的部分更加简单，简化了交互模式，状态同步可以通过状态同步的差值获得最小的数据变更，通过增量的传输得到最小的数据传输量。通过这样的协议设计，微信可以确保消息是稳定到达的，而且是按序到达。引用一句俗话：比它炫的没它简单，比它简单的没它快，没谁比他更快，哪怕在GPRS下，微信也能把进度条轻易推到底。
追求完美设计的团队不能胜任海量服务
在容灾之前面向最坏的思考，如果系统真的挂了，需要做一些事情，首先是防止雪崩，避免蝴蝶效应。如果关注春节订火车票就知道了，用户的请求量会因为系统服务不了而不断的重试，意味着发生雪崩的时候，系统可能会承载原先3-10倍的流量，使得所有的事情更加恶化。所以微信有很多“放雪”功能的设计。
第二个词是柔性可用，在任何的系统中不要追求完美设计，追求完美设计的是团队是不能胜任海量服务的。如果在一个系统出现问题的时候，这个系统就挂了，那么这是一个不好的设计，最好的做法是提供0-1中间的选择。举一个例子，当一个用户向另外一个用户发消息的时候，可能会通过一个垃圾信息过滤的检测，如果垃圾信息过滤这个模块突然挂掉了，这个消息难道就不能达到了吗？在这样的情况下，要忽略掉这个错误，使得消息正常达到对方。要精确定位出哪一个环节是最为重要的，把不是重要的错误尽可能的忽略掉。当不能做到完美的时候，尽可能为用户提供服务。
另外一个重要方面叫做“保护点前置”，最前的一个点就是终端，在手机终端上蕴埋更多的保护点，这样会为用户系统赢得更大的处理空间。如果终端具备这样的能力，会获得更大的反应空间。
周颢介绍了在微信上具体容灾设计的做法。在所有的容灾中存储层的容灾是最难的，一个系统的设计分为三层：接入层、逻辑层、存储层。接入层和逻辑层的容灾都有比较成熟的方案。
逻辑层的容灾相对来说比较简单，尽量不要有状态的设计，比如说当你做上一个请求的时候，会保持一些状态，要使得下一个请求发到下一个服务器。如果任何一个请求之间互相不关联的话，这个就是无状态的设计，只要做到这一点逻辑层的容灾可以随意的切换。在回到存储层本身的容灾设计上，相对来说困难一些，但是微信研发团队采用了一些技巧，叫分而治之，分离业务场景，寻求简单的设计，并不会寻求大而同一的解决方案，因为这样会使得系统的复杂度大幅度上升，而微信会尽可能把产品拆细，寻求简化的设计。
首先是主备容灾，这是最常见的方案。在有一些业务场景中是可以容忍最终一致性的，比如账号系统的设计，每天写入账号系统的请求是非常少的，但是访问的请求非常多，这个差异可能会达到数万倍的规模，在这样的场景下，微信会在账号系统中采用简化的方案，也可以获得比较大的稳定度。
SET模型 双写
第二种容灾的模式叫双写，两台Master的机器，当一台机故障的时候，另外一台机还是可以接收到写请求，当两台机交错启动的时候，会得到数据的丢失。但是有一些场景是可以容忍轻度数据丢失的，比如说会有一个存储专门记录用户终端的类型，比如说安卓还是塞班以及他们使用终端的微信版本是什么，这样的数据是可以容忍轻度数据丢失的，因为偶尔有一些丢失的话，下一次访问会把这些数据带上来，会尽快的修复所有的数据。双写也是非常简单的模式。
微信的研发团队做了一个叫Simple Quorum的机制，在微信的后台中，同步协议有一个很重要的基石叫序列发生器，这样的一个序列发生器需要有极高的稳定度。首先可以看到序列号有一个特点永远是递增的，用递增方式往前推进的时候，最大的序列号就是最新的系列号。有一个毕业才加入广研的毕业生想到一个绝佳的方案，按SET分布，从2G减到 200K。
前轻后重，功能点后移
周颢还谈到了轻重的概念。这个概念的提出主要是从终端本身的一些困境所带来的。首先在终端上需要表现最多的一个产品的逻辑，逻辑非常复杂，变更的成本也非常高，当需要修复的时候必须发布一个新版本，这个新版必须由自己下载才能完成，下载的成本非常高。在这样的前提下，如果手机终端产生了任何变化的时候，如果这个变化有非常大的问题就会有极大的困境，所以需要在每一个发布之前做一些充分的数据，确保不会发生致命问题。如果一旦出现致命问题难以修复，需要把关键的点从终端移到后台实现，把功能点后移，来充分发挥后台快速变更的能力。
接入优化：从GSLB到IP重定向
在接入层的优化，速度很重要的因素，是不是能够就近接入一个最优的节点，比如说移动用户最好接入移动的节点，海外的用户可能需要寻找更佳的路由，有的时候可能无法自动做到这一点，一点是在终端上做测速，微信会通过在后台IP逆向的能力，通过后台指挥微信终端联网的能力，寻找最优的接入点。上图就是每分钟收到同一项指令曲线的报表。
如何解决“偷流量”的问题——当国内类微信类产品发布的时候出现一个大的问题就是“偷流量”，当用户在某一些逻辑下进行一个死循环，不断访问某一些数据，这样的死循环是非常可怕的，如果在用户不知觉的情况之下，可能会在一个小时之内偷到数10兆甚至数百兆的流量。有非常多业内的同行都需要花大量的精力解决这个问题，微信研发团队用了非常强大的方式解决它。通过在后台建立起严厉的监控系统，对每一个用户的行为做一个监控，当发现异常的时候，后台会给终端发出指令，使得微信终端在一段时间无法联网，但是可以保证用户流量不会白白的使用掉。
功能适配的例子——第一期微信版本发布的时候，当时没有群聊的功能，第二版发布的时候做了这个功能。当时有两个选择，对于早期版本的用户，因为不支持群聊，就无法享用到这个功能，但是微信希望提供更好的选择，想让早期不支持群聊的版本，也可以被拉到一个群里面收消息、发消息，通过后台功能的适配也能做到这个事情。
分而治之，把监控嵌入基础框架
对于一个海量系统来说，一个精密的仪表盘非常重要。监控是非常痛苦的，对于这样一个系统来说，每小时会产生数百G的监控日志。微信希望在1分钟之内监控的数据就能够显示在报表上，因为只有这样的精准和实时度才能够赢得处理故障的时间。微信会做关联统计，通过摇一摇加了好友，他们活跃度如何，过了一段时间他们的活跃度变化情况又是如何。这种需求是需要通过大量日志的关联统计来获得的。研发团队也花了一段时间来理解这个问题，发现了中间一个重要的经验叫做“鱼和熊掌不能兼得”。
为了让监控数值更敏感，需要把监控细化再细化，上面数据表示每一栏子系统的数据，下面这个是按微信版本号来划分的，这里的数据项是非常多。
微信还需要采集一些异常的点，如果有异常的话会发布紧急的版本，尽可能快的替换它。对收发消息延时做的监控，比如说0—1秒端到端的速度，会对不同的区段做一些统计，当某一个环节出现异常的时候，通常会在中间的延时上体现出来。有一个很重要的点叫自动报警，现在有数千项的数据，不可能每一项都靠人工去看的，必须要跟自动报警相关联，微信有一些智能的算法，是不是在正常的范围内，跟历史的数值进行对比，如果有异常的话，会通过短信、邮件还有微信本身来发出报警信息。
把监控嵌入基础框架
微信会把监控嵌入到基础框架里面去，因为并不是每一个人都会意识到在需要的地方嵌入一个监控点，所以在基础框架本身内置很重要的监控点，比如说这个表上的栏目，非常多的栏目大概会有数百项的栏目，都不需要程序员自己去写，当用基础组件搭建一个系统的时候，就可以直接观测系统数据。
在谈到微信未来的技术挑战时，周颢首先希望能够让微信成为可用性99.99%的系统;设计出面向现在10倍容量的系统以及完全的容灾。
喜欢该文的人也喜欢