标签：
最近接了一个B2C外包，据称初期用户量大概2000，并发量希望能支撑得起至少300次访问每秒。老实说，这个需求来说，用普通的架构一个好点的服务器加点优化都是卓卓有余的了。。但是在重温完《淘宝技术这十年》这本书以后，心中悸动不已，幻想都够架构出一个几万乃至上十万的并发系统，但是实习的时候是做游戏前端，平时接的项目都是小项目，基本没接触过高大上的大项目，所以想对手中这个小项目进行步步优化，看看能到什么程度（当然了，后面可能换别的项目）。
目前项目的基本业务功能都已经完成实现，环境是LAMP，用的是一个基于国产框架Thinkphp的系统二次开发，本来习惯做的一套优化都停住了先，先跟着《淘》进行优化。而目前的项目系统服务端经过压力测试在500用户连接、200并发操作的返回时间符合理想预期（暂时未加入日志系统）。为了让目标最大化，这里把客户要求的目标用户量和并发量都乘以十倍。
项目是一个B2C的电商系统，主要模块分为商品模块，着装搭配信息模块，用户模块，订单模块。
当前的系统数据库访问就是最简单的一个库，读写都在上面，优点就是简单。。缺点也很明显，就是数据库访问的瓶颈。因此，第一步的优化就是考虑主从分库（如下图）。进行主从库分离后主要有以下优点：
1. 读写效率得到提升，因为写操作比读操作更加消耗资源，分开后互不干扰
2. 存储容量增加，可多个从库存储不同表数据，通过数据访问层决定在哪个库读取，这里也带出联合查询等等的问题，这是后话。
3. 数据安全性，有了从库的备份，也使得数据的安全性有一定的保证，当然了，定时备份还是必不可少的。
从项目上来看，抛开日志系统来说，频繁的写操作主要集中在用户的评论和购买时候生成的订单信息，而主要的读操作就集中在商品信息、评论信息、订单信息、搭配文章信息，用户信息在用户行为角度考虑的话在B2C系统上读取频率相对较少。因此这里的设计是，一个主数据库：存储所有的信息数据，负责各种的写操作；从数据库1：负责存储订单信息、评论信息和搭配文章信息；从数据库2：负责存储商品信息。
// 通过搜索资料，MySQL就自带了主从库分库的功能，因为硬件设备的缺乏，这里的实验就把两个从库放在一个服务器上，换个端口。
// 主要的实现明天实验过后再更新
标签：
原文地址：http://my.oschina.net/u/203607/blog/417009
