引入搜索引擎实现全文搜索：
网站演变到这里,我们需要知道问题的核心在哪里，数据库中的数据最终是要让用户可以查询到的，因为 用户不能在你的网站一个一个网页去翻，然后去找到自己需要的商品，通常都是通过搜索定位到他们需要的商品，那这时仅靠MySQL很难实现了，因为我们的电商网站的数据库是需要支持事务，但MyISAM存储引擎支持全文索引，但不支持事务，所以它并非最佳途径，我们就需要另拿一台服务器专门安装MySQL使用支持全文索引的存储引擎，将现有MySQL的Slave节点上将数据都读出来，在它上面做全文索引，然后，前端自己开发的索引引擎，通过搜索全文索引数据库，来响应用户的搜索请求，所以Slave读取Master上数据的及时性就显得很重要了，因为新上架是商品能否让用户看到，取决于搜索库中有没有从Slave库中读到新商品数据。
引入缓存
当我们的网站中应用服务器的压力主要集中在对很多静态内容的处理上时，那我们就需要使用动静分离技术，但比它更使用的此时应该是缓存，在负载均衡器后面第一级，先引入缓存，把不变化的静态内容直接缓存在应用服务器的前端缓存服务器中，甚至还可以使用AJAX技术实现缓存网页中的一部分数据，另外一部分变化的数据，到后端去计算后得到，比如一个淘宝页面，第一用户看商品页面和第二个用户看的商品页面是一样的，这时就可以缓存这个页面，但有可能第二个用户看时，这个商品已经卖出去了2个，所以仅需要从后端应用服务器上获取这部分变化的库存量信息就可以了，这样可以更大程度减少后端的压力。
引入缓存要考虑两个方面的问题:
1.页面缓存
varnish， squid
2.数据库缓存
因为数据库节点可能也会逐渐增加，而查询缓存仅在数据库本地有效，为了提高命中率，增加数据库缓存也是必须的。
对于数据库缓存，要使用Key-Value类型的存储，而Memcached是其中最具代表性的。
若引入Memcached，将会引入新问题:
a. 需要自行开发程序调用Memcached的API实现存储。
b. 需要自行管理其数据有效期。
注意：
引入缓存，可能不会只有一台，或者说会逐渐增加成多台，这时我们就可以称这种缓存架构为分布式缓存，在分布式缓存中，要提高数据的命中率，就必须使用哈希算法，来提高命中率。
当网站规模继续增大时，接下来面临压力的一定就是数据库的写库。
对于数据库写库的分担，只有数据库拆分这一条路.
垂直拆分：把数据库中不同的业务的数据拆分到不同的数据库中,它缓解的是读压力.
假如以电商网站来说:将它的用户表，交易表，商品表分别分到三个库，但我们知道，
我们到淘宝上买的东西，我们会去搜索用户吗？会搜索其他人的交易信息吗？
不会,甚至也不允许,所以商品表被读的压力就会很大，因此它是一定要做主从的，
其它库可以从数据安全性角度来说，也可以做主从。
由于数据库级别拆分成多个了，这时我们访问数据库就必须要知道我们访问的数据在哪里
所以前端应该还要有规则服务器来告知前端应用数据在那台后端数据库上。
静态内容: 如用户证书，用户生物信息，交易历史记录，商品图片等
FTP上传: 如: 商品图片，用户身份证图片，文档等
水平拆分：把一个单独的表中的数据拆分到多个不同的数据库服务器中，它缓解的是写压力。
假如马上要到剁手节，将产生大量用户产生交易信息，交易表可能受不了，那怎么办？
这就需要分担对交易表的写压力，对交易表我们可以根据用户年龄来拆分，将年轻群体
中消费能力弱的18-20的分到一张表，消费能力较强的21-25分一张表，26-29分一张表,
等等，来拆分表，但是表拆分完了后，该怎么去访问？前端应用怎么知道我要访问的数据
在哪里存储？由此规则服务就更加重要了。