大型应用架构思路

 

可能很多开发者没有机会接触到大型应用的开发中，对大型应用的架构充满了好奇，经常在想怎样处理上亿的pv和亿万级的数据规模？

 

其实如问题所述，我们主要需要要解决2个问题：

 

首先要解决吞吐量问题：

 

1、对于同构无状态的模块，比如apache，天然具备可横向扩展性，加机器即可解决。

2、对于异构或有状态的模块，比如存储模块mysql，虽然同构但因为不同的机器存储的数据不同所以是有状态的，如何来实现横向扩展来满足日益增加的读写吞吐量问题？我们可以将模块的操作分为读和写操作，对于读操作，如果能保证一份数据能一致性的存储在多台机器，横向扩展则不是问题，对于写操作，显然不能对同一份数据的多处写入，因为会带来数据不一致的问题，因此我们暂时只能实现一处写多处读的设计，就像mysql的主从复制机制。

 

如果对于并发写操作量不大，且在可预见的范围增加的并发写操作量单台mysql完全能承受的话，那么上述的方式没什么问题。

如果并发写操作量单台mysql已经无法承受，该怎么办？思路无非是提高模块的写并发能力或者降低并发写量。

对于提高写并发能力：换处理性能更好、内存更大、硬盘IO更快的mysql机器，会是一种思路。

对于降低并发写量：写操作并不是均匀的（每日），而是会存在高峰并发，如果我们能将写请求均匀的分布在24小时的话，那么并发的写操作自然就下降了，那么用队列缓存写操作命令，来实现异步操作会是一种思路，另外将数据根据独立性划分到不同物理机器，也是一种思路。

 

事实上，上面的这种架构已经具备搞定很大规模网站的能力了。

我们依然继续，上面的方式存在明显的几个问题：

1、异步写失败如何处理？

可人工处理，日志恢复。

2、先写后读如何保证读到最新的？

对于非高峰期，数据延迟基本很小，且内网网速要远大于外网网速，因此绝大部分情况下能读到最新的，对于高峰期延迟可能性变大，需要看应用是否能够容忍。

3、完全抛弃了事务

还好了，相比事务的实现代价而言，绝大多数网站对事务没那么严格。

4、异步队列是个单点，挂了怎么办？

可在命令执行前将命令复制到硬盘持久化，或者将命令复制到其他机器，并记录当前已执行到的命令，当机器挂掉后，可立马切换到复制机器，从而避免命令的丢失。

 

为了进行快速的读操作，采用缓存以一种思路。

最后，考虑南北分流和跨机房问题，采用多组存储群（每个机房一个）是一种思路。

 

（未完待续）