软件/网站稳定性设计原则二：备份能多一个就多一个

　　去年二月前后到现在的公司里，到现在总共有三台服务器。公司做了两个APP，几乎每隔两三天就会出现访问不了的情况出现，因为服务器权限不在我手中，而且老大似乎不愿意让我去操作服务器，所以没办法去排查异常。

　　从春节前后，我开始学习大并发、大数据量的相关技术，前后研究了NGINX、REDIS、SQL SERVER读写库、RABBITMQ，但是苦于没有合适的应用环境。终于有一天我发现REDIS有一个应用环境：我写的.NET程序原本使用自带的CACHE，但是因为接口、后台不在同一个网站中，这就导致了CACHE不能通用，很多数据的更新速度极慢。于是我决定在其中一台服务器上部署REDIS，如果后台有数据改动就刷新REDIS数据，这样数据几乎就是实时的了。

　　老大也同意了这个方案，于是在经过了一周的紧张工作之后，REDIS部署成功，各个项目的缓存也都切入了REDIS，初步测试运行正常。然而意想不到的是，在两天以后出现了一次故障，造成所有的.NET接口都无法访问。

　　我立即想到是那台部署了REDIS的服务器异常，因为以前另外一个APP的接口部署在这台服务器A上，之前曾经出现过很多次问题。而我做的那个APP接口部署在服务器B上，接口从来都运行正常。于是我立即就想到服务器A可能不正常，因为是在部署了REDIS以后接口才出现异常——鉴于之前老大不愿意给我服务器权限，这次我也不打算再去碰运气了。

 

　　刚刚说过我今年接触的技术还有NGINX，有一天突发奇想，如果在我那个部署接口的服务器上部署NGINX，然后把所有接口都转接到NGINX服务器，由NGINX服务器作转发，这样一台服务器崩掉以后会立即切到另一台，这样子会不会好一些？随后在群里问了一些牛人，我得到的答复是完全可以，如果把NGINX局限在大并发场景，思维局限性就太强了。

　　同时还有个类似的考虑，REDIS也可以作多服务器部署，形成主从模式的集群，并以哨兵不断的监控运行情况，可以让其中一台服务器故障时立即切入其他服务器。之前我做REDIS的时候只考虑到它是一个缓存服务器，并没有想太多其他的。

　　等最近手头的事情结束掉，我立即部署NGINX和REDIS，希望未来网站运行几个月也不要出一次故障吧，毕竟目前的访问量并不大，出故障很难堪的。