回首2016对数据的处理

      所有的设计模式，总是在实践中一步一步中衍生出来的。所谓，有需求，才有解决方案。

     1.问题的出现：请求接口数据，接口response回来数据，客户端渲染数据。一般的实现流程大概都是这样的，而且，正常情况下，也是没问题的。但是，如果在某一时刻有大量用户并发访问了同一个接口的数据，服务器是否能够支持了住呢？

       答案是肯定的。面对这样的问题，有什么方法可以解决呢？横向的扩增服务器？ iis服务器开启多个工作进程？其实，我们都知道，上述的两种方法都可以一定程度上解决问题，但不能饮鸩止渴。横向扩增服务器，必然引起成本大大增加。开启多个iis工作进程也是建立在硬件的基础之上，扩展有限。。。

       那么，接着来讲讲我们解决的办法吧？其实，很多问题的解决都是要依靠场景来考虑的。针对场景，才能设计出最合脚的设计。首先，我们的数据有一下特点，

       a.大多数数据在相对的时间里面是稳定的，不变化的。（说这个的时候，你或许想到了什么？灵光一闪而过，嗯。你很有天赋哦^.^）

       b.数据库连接数有限

       c.一些配置性的东西相对稳定，基本上一设置就很少修改了。（稳定资源）

   2.问题的解决：

      针对以上的一些情况，我们首先对数据接口的数据做一些调整。按照活跃程度进行拆分到不同的接口。我们不盲目的多大接口的一次性输出。有些人甚至客户端会担心发起一些不必要的请求之类的。其实，原则大概是这样子的没错，但是，抛开场景谈原则都是扯淡不是？所以，针对场景的设计需要，我们将数据拆分成，1实时变化的或者是个性化的（针对用户开放的数据或者很短时间就会发生变动的）2.短时间内相对稳定的 （一些公共的主体数据）  3长时间稳定的（配置类的）

     略过第一种情况，我们先来说说针对第二种数据做的处理。1.在代码中加入【一级缓存】处理，这里的【一级缓存】概念其实使我们自己定义的。就是启用memoryCache，由于这类数据具有公共的特点，针对所有用户其实只要一份就足够了，所以存储在memoryCache中也不必担心过多占用服务器内存资源的额问题。如果，你考虑这方面的问题的话，那也是对的，毕竟要有持疑的学习心态。在这里，可以使用设置缓存过期时间或者使用LRU原则来处理，这里就不多涉及了。大多数情况下，使用memoryCache能有效解决减少服务器对数据的处理直接response回来。但是网络数据的出流量依然没有改变。（有大数据实战经验的人都知道，服务器瓶颈是很多方面的，但是跟木桶原理是一致的）。所以，减少网络数据的出流量成了第二阶段要解决的问题。针对这样的瓶颈。我们很直接的对数据进行身份标识。更新、修改数据都会引起数据身份的变更。但是，短时间内，数据身份没变更，就意味着数据本身没有变化。所以，在数据没有发生变化的时候，客户端只需使用上一次访问的数据就可以了，而服务端也不必要返回数据。因此，请求接口多了一个询问的过程，客户端询问服务端我的本地数据有木有发生变更，否--->>直接使用本地数据进行渲染。是--->>服务端返回数据，客户端渲染数据，并替换本地数据。

    针对第3种数据，我们统一模块下的配置统一输出，并做本地存储。同时，也保留着第二种数据一样的询问方式，防止配置数据发生变更时也能及时同步数据到客户端。

    针对第一种数据，我们针对用户性的数据使用了冷热数据处理。冷热数据处理其实是针对用户的。因为用户的个性化原因，会使数据无线的扩大。我们使用redis存储这类数据时，不免遇到大量占用内存的问题。

  3.另类的解决方案：

     其实，很多时候，如果高峰期可预见的情况下，也可以使用静态页输出来解决。但是，缺点也是很明显的，灵活性不足。