窥探Stack Overflow & Stack Exchange 的基础架构
原创窥探Stack Overflow & Stack Exchange 的基础架构
原创
Stack Overflow 对于广大的程序员来说应该并不陌生，当我们google一些开发相关问题时，被导航到Stack Overflow
的概率是非常高的。
其实不仅仅是Stack Overflow ，他们的另一款产品 Stack Exchange 也可帮助人们在需要时找到所需的答案。整个Stack Exchange Network由包括 Stack Overflow 在内的 173 个问答社区组成，每月有超过 1 亿人访问以提问、学习和分享技术知识。其产品和工具使人们能够找到他们在工作或在家中开发技术所需的东西。这些产品包括Stack Overflow for Teams、Stack Overflow Advertising、Collectives™ on Stack Overflow和Stack Overflow Talent。
业务流量
业务架构
对于一个日活过千万，月访问量过亿的系统，应该怎么设计，才能够保证满足用户的需求呢？我们可以从Stack Exchange公布的架构图可见一斑。
大量的内存消耗，意味着为了满足高吞吐低延迟的访问，大量的数据平时都是被放在内存中的。
4 台 SQL SERVERS，服务于Stack overflow的两台，配置达到了RAM: 1.5 TB • DB size: 2.8 TB
另一个有意思的现象是：在索引总体大小只有 528 GB 的情况下，配置了3台196GB RAM的Elasticsearch。几乎所有的索引都是On Heap的。而256GB的Redis，几乎把一半的ES索引都是能装载在缓存中
并且，通过他们自定义的Tag Engine，将“问题"和"回答"打上特定的标签，存储于Elasticsearch，以提升相关性。
在冗余上，可以看到所有的服务器都是双活，并且是超配（没有任何一个组件的CPU峰值是超过20%的，平均使用率都在10%以下）。这点是非常有意思的，他们追求的并非是高CPU使用，并非是ROI，而是极致的性能和稳定性
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。