有损服务

  进入互联网行业一年有余，相较于之前传统行业的服务来说，互联网服务基本都是分布式集群部署，高并发，网络环境也比较复杂，因而在互联网服务中有很多行之有效的策略用来保证服务可以外正常提供服务，有损就是其中一个屡试不爽的策略。

   下面讲讲个人对有损服务的一些理解。

   一：为什么是有损之CAP原理：

        C：（一致性）：所有的结点数据所有时刻保持完全一致。

       A：（可用性）：对服务的请求可在有限时间内得到响应

       P：（分区容错）：即使系统内存有消息丢失导致网络分区，系统也能持续对外提供服务。

 

    CAP原理指出 C、A、P最多只能满足其中的两个。

    既然如此，面对服务中的3个不可或缺的要素，该如何是好呢？

    P：分区容错，在互联网复杂多变的网络环境中，彼此间俄尔断断网失联一下是再平常不过的事情。如果动不动来一发服务不可用，那用户肯定逃之夭夭了。

    A：可用性，如果你请求一个网站一直显示正在加载中，用户必然会找别家网站了。

    C：一致性，即后台所有节点的数据保持一致，这个貌似用户感知度比较低。我把自己=的qq昵称改为“张大帅”，由于后台数据不能达到一致性，王二麻子看到的还是“张小帅”，这个好像也无伤大雅，只要过一会能看到就可以了。

 

当然了，CAP原理只是其中一种原因了，其他的还包括服务过载等。

 

二：如何有损

    1：后端对静态数据进行缓存策略。

         如目前的网站几乎都采用将一些图片等变化小的数据缓存到CDN，采用定期回 原等策略来保证数据的最终一致。这里的缓存不限于图片等静态数据。有一些变化  不频繁的计算结果也会写入到缓存中，以此达到快速给用户返回结果，减轻后端服 务压力。这里就就如memcache、redis、或者又是专门写的缓存服务。必要时可以 多级缓存。

 

    2：后端对底层返回失败的请求做兜底处理。

       在互联网业务中，一个复杂业务后台必然由分布部署的多个子模块协同工作对 外提供服务，数据在网络传输的过程有丢失、网络俄尔异常、服务本身出点问题等不可控的因素导致对外服务异常的时有发生。为了能更好的对外提供服务，对于有      些接口失败时返回事先准备好的固定值，这样可以避免在服务异常的情况下用户拉 取不到数据的情况。

 

    3：在客户端（前端）对用户的某些请求做缓存处理、或者直接兜底处理。

             同第二种情况情况类似，客户端的网络环境千差万别， 因而客户端网络超时、 数据丢失的情况更容易发生。为了给那些网络环境不好的用户跟好的体验，常常 对一些在网络失败的时候给用户出兜底数据。在请求到数据时将数据缓存一段时间，下次请求时直接取缓存内的数据，而不是去服务端拉取，另外也可以在服务异常时给用户展示缓存数据。   

 

   4：后端对业务分级处理。

            这里假设同时多外通过多种服务，有些服务很重，如qq的登入服务。有些服务不那么重要，如qq的文件传输服务。假设这两种服务同时由一个后台通过。在后台出现过载或其他一些异常而导致服务性能下降时，为了保证重要的业务（qq登入服 务）能正常对外提供服，我们只能舍弃不重要（文件传输）的服务。这个可以通过 配置或者对外提供不同的服务地址来实现。

      另外一种情况就是请求结果需要同时依赖多个接口，有些接口的数据是必不可少的，有些接口的数据即使缺失也对用户的体验影响不大。例如腾讯视频客户端后台逻辑层对外提供的接口中需要先去后台拉取一系列视频id，然后需要扩展很多一些 id的属性。在遇到拉取视频id或者一些其他重要的属性（如：标题）耗时过多时， 为了保证前端接口不超时，可以不拉取将某些不重要的属性（用户评论、用户评分） 而直接返还给用户，或者些不重要的属性拉取失败时，也可以直接给用户返回。

         

 5：后端业务隔离，对业务分开部署。

          相同的接口可能通过被前端不同的业务调用。业务的重要程度也有所区别。可以按 调用的业务不同将服务同时部署在不同的机器（集群），每个机器（集群）独立对外提供服务。对重要的业务重点关注、维护，分配更多的资源，对不太重要的业务可以投入的资源少点。