千米粒网上线已经一周了每天的PV虽不是太多但总是在不断地增长，这给我们很大的鼓励，让我们更加努力的前行。
前天写了一篇《自己做的网站上线了》因为时间匆忙没写太多就草草的结束了，今天接着上一篇继续写吧。
先说说负载均衡吧，负载均衡器分软件和硬件两种，硬件一般是有钱了才用的，我们这样的草根刚开始还是考虑使用apache的负载均衡吧，apache负载均衡配置的文章网络一大把我就不说了，拿以前配置负载均衡器的经验出来晒一下吧：
首先来说要考虑的是负载均衡模式，一般分为旁路模式和反向代理模式，旁路模式只做访问分发，分发请求以后就不管了，打个比方就是你来找我问哪里有图书卖我说你去A处，那么你以后你就会只往返于A出和你住处之间了，除非哪天你忘记了或者A处关门了你才会再次找我，我接着告诉你新的地址。那么反向代理模式则不一样你来找我问买书的地方，我说你等会我就和卓越或当当打了个电话说某某买某某书赶快送来，等书来了我在把书交到你手上，你可能知道后面有卓越或当当存在（通过输的包装即报文内容）也可能不知道他们的存在。一般对于企业内网才采用旁路模式较多，对于公网特别是我们这样只有一个域名并且没有自己的域名解析器的那还是选择反向代理模式吧。这样可以有一个公网的出口，做负载均衡，后面有N个内网机器提供服务。
其次是负载均衡算法，算法有轮询、最少连接数、最小响应时间、基于报投/请求的算法那，这里我们选择的是强轮询算法，强轮询算法在大体上是可以保证个app服务器的相对压力均衡的，最小连接数算法一般在某台服务器重启时会有问题，因为他刚开始重启时连接数很少，负载均衡一下次会把新的连接都转发过来，有可能导致服务器宕机或者响应超时。
再次是负载均衡策略，这里主要讨论一下会话保持策略，会话保持可以实现已登录到某台服务器的用户在下一次访问时继续访问原来的服务器，这样保存在服务器的session数据还可以服用。负载均衡策略可以通过插入cookie或者给予客户端ip来保持等实现。
最后是健康检查，就是要负载均衡器 检查 app服务器是否可以正常对台提供服务，常见的健康检查有tcp协议检查、http协议检查及getURL判断返回值检查，通过这机制，确保服务器为用户提供正确可靠的服务。用户再也不会得到这样请求的响应 “404 Object Not Found”，或响应内容不正确。建议采用getURL判断返回值检查，这样可以通过修改URL返回内容来实现服务器离线重新部署，要不然只要你服务器已启动就会有连接进来，不利于服务器自测和发布新东西。