5、更多服务器

　　有钱了，当然要多买些服务器。部署后快了没多久，又开始慢了。这次有更多的Web服务器，更多的数据库服务器，存在 IO与CPU争用。于是采用了BIG-IP作为负载均衡解决方案。

　　

　　

　　

　　6、现在我们在哪里：

　　

　　

　　

　　现在服务器基本上够了，但性能还是有问题，原因出在架构上。

　　数据库的架构是最大的问题。由于增加的数据库都是以Slave模式添加到应用内，这样唯一的好处就是将读操作分布到了多台机器，但这样带来的后果就是写操作被大量分发，每台机器都要执行，服务器越多，浪费就越大，随着写操作的增加，用于服务读操作的资源越来越少。

　　

　　由一台分布到两台

　　

　　

　　

　　最终效果

　　现在我们发现，我们并不需要把这些数据在如此多的服务器上都保留一份。服务器上已经做了RAID，数据库也进行了备份，这么多的备份完全是对资源的浪费，属于冗余极端过度。那为什么不把数据分布存储呢？

　　问题发现了，开始考虑如何解决。现在要做的就是把不同用户的数据分布到不同的服务器上进行存储，以实现数据的分布式存储，让每台机器只为相对固定的用户服务，以实现平行的架构和良好的可扩展性。

　　为了实现用户分组，我们需要为每一个用户分配一个组标记，用于标记此用户的数据存放在哪一组数据库服务器中。每组数据库由一个master及几个slave组成，并且slave的数量在2-3台，以实现系统资源的最合理分配，既保证数据读操作分布，又避免数据过度冗余以及同步操作对系统资源的过度消耗。

　　

　　

　　

　　由一台（一组）中心服务器提供用户分组控制。所有用户的分组信息都存储在这台机器上，所有针对用户的操作需要先查询这台机器得到用户的组号，然后再到相应的数据库组中获取数据。

　　这样的用户架构与目前LJ的架构已经很相像了。

　　在具体的实现时需要注意几个问题：

　　在数据库组内不要使用自增ID，以便于以后在数据库组之间迁移用户，以实现更合理的I/O，磁盘空间及负载分布。

　　将userid，postid存储在全局服务器上，可以使用自增，数据库组中的相应值必须以全局服务器上的值为准。全局服务器上使用事务型数据库InnoDB。

　　在数据库组之间迁移用户时要万分小心，当迁移时用户不能有写操作。

　　7、现在我们在哪里

　　

　　

　　

　　问题：

　　一个全局主服务器，挂掉的话所有用户注册及写操作就挂掉。

　　每个数据库组一个主服务器，挂掉的话这组用户的写操作就挂掉。

　　数据库组从服务器挂掉的话会导致其它服务器负载过大。

　　对于Master-Slave模式的单点问题，LJ采取了Master-Master模式来解决。所谓Master-Master实际上是人工实现的，并不是由MySQL直接提供的，实际上也就是两台机器同时是Master，也同时是Slave，互相同步。

　　Master-Master实现时需要注意：

　　一个Master出错后恢复同步，最好由服务器自动完成。

　　数字分配，由于同时在两台机器上写，有些ID可能会冲突。

　　解决方案：

　　奇偶数分配ID，一台机器上写奇数，一台机器上写偶数

　　通过全局服务器进行分配(LJ采用的做法)。

　　Master-Master模式还有一种用法，这种方法与前一种相比，仍然保持两台机器的同步，但只有一台机器提供服务（读和写），在每天晚上的时候进行轮换，或者出现问题的时候进行切换。

　　8、现在我们在哪里