在上一篇中我们配置好了主从库，现在我们尝试在程序中使用主从库。

　　主从库之间是一种发布订阅的关系，发布者和订阅者之间并非实时同步的，通常会有几分钟的延时，更有甚者会有几个小时的延时。所以我们需要通过合理的使用来避开有延时这个问题。

　　我们希望主库尽可能的少参与查询，来提高写的及时性;同时要让从库在不影响读出数据的准确及时的前提下尽可能的分担主库的压力。

　　主从两个库需要在配置文件中配置两个连接字符串，CONN_Master和CONN_Slave。我们需要设定一些规则决定当前的查询应该从主库查还是需要从从库查。这个规则没有定式，只能根据业务需要来确定。下面我举几个例子来说明：

　　1. 以豆瓣读书书的详细页为假定场景，你可以点击这里看下页面的结构(我不是豆瓣的技术，在这里只是拿这个页面举例)

　　我们来分析呈现这个页面需要的数据和这些数据的实效性要求

　　1) 书的详细信息 时效性要求：要求及时

　　2) 豆瓣成员的常用标签 实效性：不需要很及时

　　3) 喜欢读这本书的人也喜欢读的书 属于分析数据，不需要很及时

　　4) 最新书评 要求及时

　　5) 读这本书的几个用户 及时性不高

　　6) 喜欢这本书的人常去的小组 属于分析数据不需要很及时

　　从上面的分析可以看出只有1)，4)两项数据需要从主库读，而2)，3)，5)，6)为非及时数据从从库读取即可。当然我们可以对这些实效性不高的数据做缓存处理。

　　2. 以论坛帖子列表页面为假定场景，玩论坛的人都喜欢顶贴，把自己的帖子顶到第一页让更多的人关注，而对于50页之后的帖子则反读的人很少;我们可以根据这个业务逻辑特征来决定在用户访问前50页帖子列表数据时从主库读，而当用户访问超过50页之后的数据时则从从库进行查询。

　　3. 以订单为例，通常超过三个月的订单就不会再有变化了，假定我们把订单号设计为日期格式时，根据订单号去查询订单时就可以根据订单号来决定该访问主库还是从库。

　　举了几个适用的场景，我们以第三个场景为例，写一段简单的示意代码看下

01	//orderNo 的格式为 20100528120105000001 即yyyyMMddHHmmss + 序号

　　正确的使用主从库，可以很好的提升系统的性能。使用主库还是从库的选择权决定在业务逻辑的手里。