Twitter Messaging 的架构演化之路
https://v.qq.com/txp/iframe/player.html?vid=m0306t0s9jj&width=500&height=375&auto=0
Twitter 从原来的 Kestrel，Kafka 等多套不同的 Messaging 架构，演变成基于 DistributedLog / Bookkeeper 的统一的 Messaging 架构，从而服务不同负载特性的用户场景。架构演进背后都有哪些思考和经验呢？作为 DistributedLog/Bookkeeper 项目的主要负责人，郭斯杰和大家分享了一手的架构思路。
郭斯杰，目前就职于 Twitter，任职 Staff Software Engineer，是 Twitter DistributedLog / BookKeeper 的主要负责人。同时也是 Apache BookKeeper 的 PMC Chair。加入 Twitter 之前，就职于 Yahoo。
在公众号后台回复“架构”，即可下载幻灯片。
QCon 上海 2016 将于10月20~22日在上海宝华万豪酒店举行。
Twitter高级工程师黄浩届时将分享《Twitter的监控系统是如何处理十亿量级metrics的》。
Twitter的Observability Stack包含了核心的Timeseries Database、实时的监控报表系统、报警和自动故障恢复系统，以及分布式的日志分析和tracing系统。在Twitter，它是整个公司最关键的内部架构之一，是保证各个服务可用性的关键。目前整个监控报警系统每分钟处理25亿次的metrics写入，170万的复杂查询和25，000次的报警规则。日志分析系统和tracing系统是工程师们平时追查问题的主要平台。在本演讲中，黄浩将向大家分享整个架构的设计与演进中的思考和经验。
360高级工程师、资深顾问魏自立将分享《如何打造一个百万亿级的日志搜索引擎：Poseidon》。
Poseidon系统是一个日志搜索平台，可以在百万亿条、100PB大小的日志数据中快速分析和检索。360公司是一家安全公司，在追踪APT（高级持续威胁）事件，经常需要在海量的历史日志数据中检索某些信息，例如某个恶意样本在某个时间段内的活动情况。在Poseidon系统出现之前，都是写Map/Reduce计算任务在Hadoop集群中做计算，一次任务所需的计算时间从数小时到数天不等，大大制约了APT事件的追踪效率。
Poseidon系统就是为解决这个需求而设计的，能在数百万亿条规模的数据集中找出我们需要的数据，只需要花费几秒钟时间，大大提高工作效率；同时，数据不需要额外存储，节省了大量存储和计算资源。该系统可以应用于任何海量(从万亿到千万亿规模)的查询检索需求。
听众受益：Poseidon系统是大数据领域又一个简洁高效的解决方案。在数据规模达到万亿级别之后，ES等系统就解决不好了，而且相较于HBase等方案，Poseidon系统更加节省存储空间，用户友好性更好，对现有Map/Reduce、Spark等任务都无侵害性。
现在报名，可享 7 折优惠。更多信息，可点击“阅读原文”，访问大会网站。