大型分布式网站相关概念及优化

分布式系统概念

分布式系统是由一系列分散自治组件通过互联网并行并发协作，从而组成的一个coherent软件系统。

它具备资源共享，并行并发，可靠容错，透明开放等特性。

分布式概念
(1)三元组：分布式系统说白了，就是很多机器组成的集群，靠彼此之间的网络通信，担当的角色可能不同，共同完成同一个事情的系统。
1、节点 -- 系统中按照协议完成计算工作的一个逻辑实体，可能是执行某些工作的进程或机器
2、网络 -- 系统的数据传输通道，用来彼此通信。通信是具有方向性的。
3、存储 -- 系统中持久化数据的数据库或者文件存储。
(2)状态特性
各个节点的状态可以是“无状态”或者“有状态的”.
一般认为，节点是偏计算和通信的模块，一般是无状态的。这类应用一般不会存储自己的中间状态信息，比如Nginx，一般情况下是转发请求而已，不会存储中间信息。另一种“有状态”的，如MySQL等数据库，状态和数据全部持久化到磁盘等介质。“无状态”的节点一般我们认为是可随意重启的，因为重启后只需要立刻工作就好。“有状态”的则不同，需要先读取持久化的数据，才能开始服务。所以，“无状态”的节点一般是可以随意扩展的，“有状态”的节点需要一些控制协议来保证扩展。
(3)系统异常
异常，可认为是节点因为某种原因不能工作，此为节点异常。还有因为网络原因，临时、永久不能被其他节点所访问，此为网络异常。在分布式系统中，要有对异常的处理，保证集群的正常工作。

分布式基础理论：CAP，BASE，Paxos，事务

1.CAP理论:一致性（Consistency），可用性（Availability），分区容忍性（Partition tolerance）

1.Consistency一致性，Eric Brewer（CAP理论提出者）用一个服务要么被执行，要么不被执行来定义(原文：A service that is consistent operates fully or not at all)。请注意，这里的一致性是有别于数据库ACID属性中的C，数据库层面的C指的是数据的操作不能破坏数据之间的完整性约束，如外键约束。在分布式环境中，可以把C简单理解为多节点看到的是数据单一或者同一副本。
2.Availability可用性，意味着服务是可用的。可用性又可以细分为写可用和读可用。在分布式环境中，往往指的是系统在确定时间内可返回读写操作结果，也即读写均可用。
3.Partition tolerance分区容忍性，除了整个网络故障外（如光纤被掘断），其它故障（如丢包、乱序、抖动、甚至是网络分区节点 crash ）都不能导致整个系统无法正确响应。

2.BASE理论:基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency）

eBay的架构师Dan Pritchett，在ACM上发表文章提出。BASE理论是对CAP理论的延伸，核心思想是即使无法做到强一致性（Strong Consistency，CAP的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。
1.基本可用（Basically Available）是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。
电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现。
2.软状态（ Soft State）软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现。 
3.最终一致性（ Eventual Consistency）是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

3.Paxos:分布式一致性算法

提议者Proposer、接受者Acceptor、提案Proposal的proposal_id
总体说来，paxos就是通过两个阶段确定一个决议：
Phase1：确定谁的编号proposal_id最高，只有编号最高者才有权利提交proposal；
Phase2：编号最高者提交proposal，如果没有其他节点提出更高编号的proposal，则该提案会被顺利通过；否则，整个过程就会重来。
你编号高，我比你更高，反复如此，算法永远无法结束，这叫活锁。活锁便是Paxos无法解决的硬伤.

4.事务

分布式事务，常见两个处理办法就是两段式提交和补偿。
1.两段式提交:
a. 协调员服务器发送一条投票请求消息给所有参与这次事务的参与者服务器。
b. 当一个参与者收到一条投票请求，它会向协调员发送一条响应请求消息:YES/NO。如果参与者投票NO，意味着参与者不参与这次事务，等价于ABORT决定，事务终止。
c. 协调员收集所有参与者的投票都是YES，则COMMIT，并把COMMIT消息发送给所有参与者。否则ABORT，协调员会把ABORT消息发给那些投票为YES的那些参与者
2.补偿
先处理业务，然后定时或者回调里，检查状态是不是一致的，如果不一致采用某个策略，强制状态到某个结束状态。
思路：事务拆分，大的业务流程，转化成几个小的业务流程，加入中间状态，考虑最终一致性。
复杂的业务交互过程中，不建议使用强一致性的分布式事务。解决分布式事务的最好办法就是不考虑分布式事务。就像刚说的问题一样，把分布式的事务过程拆解成多个中间状态，中间状态的东西不允许用户直接操作，等状态都一致成功，或者检测到不一致的时候全部失败掉。就解耦了这个强一致性的过程。

分布式系统与单节点的不同

 1.网络传输

在unix/linux/mac(类Unix)环境下，两个机器通信（socket），传输数据是read()/write()系统调用，把一段内存缓冲区发出去。发送数据需要走内核->网卡->链路->对端网卡->内核，路径太长只能是异步操作。write()把数据写入内核缓冲区之后就返回到应用层了，具体后面何时发送、怎么发送、TCP怎么做滑动窗口、流控都是tcp/ip协议栈内核的事情了。
所以在应用层，能确认对方受到了消息只能是对方应用返回数据，逻辑确认了这次发送才认为是成功的。
这就却别与单系统编程，大部分系统调用、库调用只要返回了就说明已经确认完成了。

 2.不可控的状态

在单系统编程中，我们对系统状态是非常可控的。比如函数调用、逻辑运算，要么成功，要么失败，因为这些操作被框在一个机器内部，cpu/总线/内存都是可以快速得到反馈的。开发者可以针对这两个状态很明确的做出程序上的判断和后续的操作。
而在分布式的网络环境下，这就变得微妙了。比如一次rpc、http调用，可能成功、失败，还有可能是“超时”，这就比前者的状态多了一个不可控因素，导致后面的代码不是很容易做出判断。试想一下，用A用支付宝向B转了一大笔钱，当他按下“确认”后，界面上有个圈在转啊转，然后显示请求超时了，然后A就抓狂了，不知道到底钱转没转过去，开始确认自己的账户、确认B的账户、打电话找客服等等。
所以分布式环境下，我们的其实要时时刻刻考虑面对这种不可控的“第三状态”设计开发，这也是挑战之一。

 3.视”异常“为”正常“

单系统下，进程/机器的异常概率十分小。即使出现了问题，可以通过人工干预重启、迁移等手段恢复。
但在分布式环境下，机器上千台，每几分钟都可能出现宕机、死机、网络断网等异常，出现的概率很大。所以，这种环境下，进程core掉、机器挂掉都是需要我们在编程中认为随时可能出现的，这样才能使我们整个系统健壮起来，所以”容错“是基本需求。
异常可以分为如下几类：
节点错误：一般是由于应用导致，一些coredump和系统错误触发，一般重新服务后可恢复。
硬件错误：由于磁盘或者内存等硬件设备导致某节点不能服务，需要人工干预恢复。 
网络错误：由于点对点的网络抖动，暂时的访问错误，一般拓扑稳定后或流量减小可以恢复。
网络分化：网络中路由器、交换机错误导致网络不可达，但是网络两边都正常，这类错误比较难恢复，并且需要在开发时特别处理。【这种情况也会比较前面的问题较难处理】

分布式系统设计策略

 1.重试机制

一般情况下，写一段网络交互的代码，发起rpc或者http，都会遇到请求超时而失败情况。可能是网络抖动(暂时的网络变更导致包不可达，比如拓扑变更)或者对端挂掉。这时一般处理逻辑是将请求包在一个重试循环块里，如下：
int retry = 3;  
while(!request() && retry--)  
  sched_yield();   // or usleep(100)  
此种模式可以防止网络暂时的抖动，一般停顿时间很短，并重试多次后，请求成功！但不能防止对端长时间不能连接(网络问题或进程问题)

 2.心跳机制

心跳顾名思义，就是以固定的频率向其他节点汇报当前节点状态的方式。收到心跳，一般可以认为一个节点和现在的网络拓扑是良好的。当然，心跳汇报时，一般也会携带一些附加的状态、元数据信息，以便管理。但心跳不是万能的，收到心跳可以确认ok，但是收不到心跳却不能确认节点不存在或者挂掉了，因为可能是网络原因倒是链路不通但是节点依旧在工作。
所以切记，”心跳“只能告诉你正常的状态是ok，它不能发现节点是否真的死亡，有可能还在继续服务。(后面会介绍一种可靠的方式 -- Lease机制)

 3.副本

副本指的是针对一份数据的多份冗余拷贝，在不同的节点上持久化同一份数据，当某一个节点的数据丢失时，可以从副本上获取数据。数据副本是分布式系统解决数据丢失异常的仅有的唯一途径。当然对多份副本的写入会带来一致性和可用性的问题，比如规定副本数为3，同步写3份，会带来3次IO的性能问题。还是同步写1份，然后异步写2份，会带来一致性问题，比如后面2份未写成功其他模块就去读了(下个小结会详细讨论如果在副本一致性中间做取舍)。

 4.中心化/无中心化

系统模型这方面，无非就是两种：
中心节点，例如mysql的MSS单主双从、MongDB Master、HDFS NameNode、MapReduce JobTracker等，有1个或几个节点充当整个系统的核心元数据及节点管理工作，其他节点都和中心节点交互。这种方式的好处显而易见，数据和管理高度统一集中在一个地方，容易聚合，就像领导者一样，其他人都服从就好。简单可行。
但是缺点是模块高度集中，容易形成性能瓶颈，并且如果出现异常，就像群龙无首一样。
无中心化的设计，例如cassandra、zookeeper，系统中不存在一个领导者，节点彼此通信并且彼此合作完成任务。好处在于如果出现异常，不会影响整体系统，局部不可用。缺点是比较协议复杂，而且需要各个节点间同步信息。

大型网站架构演化

(1) 初始阶段：独立服务器
应用服务器、文件服务、数据库服务所有资源在同一台服务器
(2) 起步阶段：应用与数据分离，不同特性服务器承担不同服务角色。
应用服务器，文件服务器和数据库服务器对硬件资源要求各不相同，分离承担不同角色服务
(3) 提升阶段：使用缓存技术和数据库读写分离
网站访问遵循二八定律，缓存热点数据，提升网站访问速度，降低数据服务访问压力
(4) 进化阶段1：应用服务器集群：实现负载均衡
集群是解决高并发，海量数据问题的常用手段，引入负载均衡服务器实现系统访问请求的分发，实现系统的可伸缩性
(5) 进化阶段2：分布式数据库，实现读写分离
用户达到一定规模，缓存仍不能解决数据库服务瓶颈问题，搭建数据库主从架构，实现读写分离
(6) 进化阶段3：面对复杂网络环境，使用反向代理和CDN加速网站响应，提升缓存能力，加快用户访问速度
反向代理：部署在网站中心机房；CDN(内容分发网络)：部署在网络提供商机房

分布式系统优化

1. I/O优化

增加缓存，减少磁盘的访问次数。
优化磁盘的管理系统，设计最优的磁盘方式策略，以及磁盘的寻址策略，这是在底层操作系统层面考虑的。
设计合理的磁盘存储数据块，以及访问这些数据库的策略，这是在应用层面考虑的。例如，我们可以给存放的数据设计索引，通过寻址索引来加快和减少磁盘的访问量，还可以采用异步和非阻塞的方式加快磁盘的访问速度。
应用合理的RAID策略提升磁盘I/O。

2. Web前端调优

减少网络交互的次数（多次请求合并）
减少网络传输数据量的大小(压缩)
尽量减少编码（尽量提前将字符转化为字节，或者减少从字符到字节的转化过程。）
使用浏览器缓存
减少Cookie传输
合理布局页面
使用页面压缩
延迟加载页面
CSS在最上面，JS在最下面
CDN
反向代理
页面静态化
异地部署

3.服务降级（自动优雅降级）

拒绝服务和关闭服务

4.幂等性设计

有些服务天然具有幂等性，比如讲用户性别设置为男性，不管设置多少次，结果都一样。但是对转账交易等操作，问题就会比较复杂，需要通过交易编号等信息进行服务调用有效性校验，只有有效的操作才能继续执行。
（注：幂等性是系统的接口对外一种承诺(而不是实现), 承诺只要调用接口成功, 外部多次调用对系统的影响是一致的. 声明为幂等的接口会认为外部调用失败是常态, 并且失败之后必然会有重试.）

5.失效转移

若数据服务器集群中任何一台服务器宕机，那么应用程序针对这台服务器的所有读写操作都需要重新路由到其他服务器，保证数据访问不会失败，这个过程叫失效转移。
失效转移包括：失效确认（心跳检测和应用程序访问失败报告）、访问转移、数据恢复。
失效转移保证当一个数据副本不可访问时，可以快速切换访问数据的其他副本，保证系统可用。

6.性能优化

根据网站分层架构,性能优化可分为：web前端性能优化、应用服务器性能优化、存储服务器性能优化。
1. web前端性能优化
浏览器访问优化：减少http请求;使用浏览器缓存;启用压缩;css放在页面最上面、javaScript放在页面最下面;减少Cookie传输
CDN加速
反向代理
2. 应用服务器性能优化
分布式缓存（Redis等）
异步操作（消息队列）
使用集群（负载均衡）
代码优化
3. 存储性能优化
机械硬盘vs固态硬盘
B+树 vs LSM树
RAID vs HDFS

7. 代码优化

多线程（Q:怎么确保线程安全？无锁机制有哪些？）
资源复用（单例模式，连接池，线程池）
数据结构
垃圾回收

8. 负载均衡

HTTP重定向负载均衡
当用户发来请求的时候，Web服务器通过修改HTTP响应头中的Location标记来返回一个新的url，然后浏览器再继续请求这个新url，实际上就是页面重定向。通过重定向，来达到“负载均衡”的目标。例如，我们在下载PHP源码包的时候，点击下载链接时，为了解决不同国家和地域下载速度的问题，它会返回一个离我们近的下载地址。重定向的HTTP返回码是302。
优点：比较简单。
缺点：浏览器需要两次请求服务器才能完成一次访问，性能较差。重定向服务自身的处理能力有可能成为瓶颈，整个集群的伸缩性国模有限；使用HTTP302响应码重定向，有可能使搜索引擎判断为SEO作弊，降低搜索排名。

DNS域名解析负载均衡
DNS（Domain Name System）负责域名解析的服务，域名url实际上是服务器的别名，实际映射是一个IP地址，解析过程，就是DNS完成域名到IP的映射。而一个域名是可以配置成对应多个IP的。因此，DNS也就可以作为负载均衡服务。
事实上，大型网站总是部分使用DNS域名解析，利用域名解析作为第一级负载均衡手段，即域名解析得到的一组服务器并不是实际提供Web服务的物理服务器，而是同样提供负载均衡服务的内部服务器，这组内部负载均衡服务器再进行负载均衡，将请求分发到真是的Web服务器上。
优点：将负载均衡的工作转交给DNS，省掉了网站管理维护负载均衡服务器的麻烦，同时许多DNS还支持基于地理位置的域名解析，即会将域名解析成举例用户地理最近的一个服务器地址，这样可以加快用户访问速度，改善性能。
缺点：不能自由定义规则，而且变更被映射的IP或者机器故障时很麻烦，还存在DNS生效延迟的问题。而且DNS负载均衡的控制权在域名服务商那里，网站无法对其做更多改善和更强大的管理。

反向代理负载均衡
反向代理服务可以缓存资源以改善网站性能。实际上，在部署位置上，反向代理服务器处于Web服务器前面（这样才可能缓存Web相应，加速访问），这个位置也正好是负载均衡服务器的位置，所以大多数反向代理服务器同时提供负载均衡的功能，管理一组Web服务器，将请求根据负载均衡算法转发到不同的Web服务器上。Web服务器处理完成的响应也需要通过反向代理服务器返回给用户。由于web服务器不直接对外提供访问，因此Web服务器不需要使用外部ip地址，而反向代理服务器则需要配置双网卡和内部外部两套IP地址。
优点：和反向代理服务器功能集成在一起，部署简单。
缺点：反向代理服务器是所有请求和响应的中转站，其性能可能会成为瓶颈。

LVS-NAT:修改IP地址
LVS-TUN: 一个IP报文封装在另一个IP报文的技术。
LVS-DR:将数据帧的MAC地址改为选出服务器的MAC地址，再将修改后的数据帧在与服务器组的局域网上发送。

9.缓存

缓存就是将数据存放在距离计算最近的位置以加快处理速度。缓存是改善软件性能的第一手段，现在CPU越来越快的一个重要因素就是使用了更多的缓存，在复杂的软件设计中，缓存几乎无处不在。大型网站架构设计在很多方面都使用了缓存设计。
CDN: 内容分发网络，部署在距离终端用户最近的网络服务商，用户的网络请求总是先到达他的网络服务商哪里，在这里缓存网站的一些静态资源（较少变化的数据），可以就近以最快速度返回给用户，如视频网站和门户网站会将用户访问量大的热点内容缓存在CDN中。
反向代理：反向代理属于网站前端架构的一部分，部署在网站的前端，当用户请求到达网站的数据中心时，最先访问到的就是反向代理服务器，这里缓存网站的静态资源，无需将请求继续转发给应用服务器就能返回给用户。
本地缓存：在应用服务器本地缓存着热点数据，应用程序可以在本机内存中直接访问数据，而无需访问数据库。
分布式缓存：大型网站的数据量非常庞大，即使只缓存一小部分，需要的内存空间也不是单机能承受的，所以除了本地缓存，还需要分布式缓存，将数据缓存在一个专门的分布式缓存集群中，应用程序通过网络通信访问缓存数据。
使用缓存有两个前提条件，一是数据访问热点不均衡，某些数据会被更频繁的访问，这些数据应该放在缓存中；二是数据在某个时间段内有效，不会很快过期，否则缓存的数据就会因已经失效而产生脏读，影响结果的正确性。网站应用中，缓存处理可以加快数据访问速度，还可以减轻后端应用和数据存储的负载压力，这一点对网站数据库架构至关重要，网站数据库几乎都是按照有缓存的前提进行负载能力设计的。

10. 负载均衡算法

轮询 Round Robin
加强轮询 Weight Round Robin
随机 Random
加强随机 Weight Random
最少连接 Least Connections
加强最少连接
源地址散列 Hash

其他算法
最快算法(Fastest)：传递连接给那些响应最快的服务器。当其中某个服务器发生第二到第7 层的故障，BIG-IP 就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。
观察算法(Observed)：连接数目和响应时间以这两项的最佳平衡为依据为新的请求选择服务器。当其中某个服务器发生第二到第7 层的故障，BIG-IP就把其从服务器队列中拿出，不参加下一次的用户请求的分配，直到其恢复正常。
预测算法(Predictive)：BIG-IP利用收集到的服务器当前的性能指标，进行预测分析，选择一台服务器在下一个时间片内，其性能将达到最佳的服务器相应用户的请求。(被BIG-IP 进行检测)
动态性能分配算法(Dynamic Ratio-APM):BIG-IP 收集到的应用程序和应用服务器的各项性能参数，动态调整流量分配。
动态服务器补充算法(Dynamic Server Act.):当主服务器群中因故障导致数量减少时，动态地将备份服务器补充至主服务器群。
服务质量算法(QoS):按不同的优先级对数据流进行分配。
服务类型算法(ToS): 按不同的服务类型(在Type of Field中标识)负载均衡对数据流进行分配。
规则模式算法：针对不同的数据流设置导向规则，用户可自行

11. 扩展性和伸缩性的区别

扩展性：指对现有系统影响最小的情况下，系统功能可持续扩展或替身的能力。表现在系统基础设施稳定不需要经常变更，应用之间较少依赖和耦合，对需求变更可以敏捷响应。它是系统架构设计层面的开闭原则（对扩展开放，对修改关闭），架构设计考虑未来功能扩展，当系统增加新功能时，不需要对现有系统的结构和代码进行修改。
衡量网站架构扩展性好坏的主要标准就是在网站增加新的业务产品时，是否可以实现对现有产品透明无影响，不需要任何改动或者很少改动既有业务功能就可以上线新产品。不同产品之间是否很少耦合，一个产品改动对其他产品无影响，其他产品和功能不需要受牵连进行改动。
伸缩性：所谓网站的伸缩性指是不需要改变网站的软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力。
指系统能够增加（减少）自身资源规模的方式增强（减少）自己计算处理事务的能力。如果这种增减是成比例的，就被称作线性伸缩性。在网站架构中，通常指利用集群的方式增加服务器数量、提高系统的整体事务吞吐能力。
衡量架构伸缩性的主要标准就是可以用多台服务器构建集群，是否容易向集群中添加新的服务器。加入新的服务器后是否可以提供和原来服务无差别的服务、集群中的可容纳的总的服务器数量是否有限制。

12.分布式缓存的一致性hash

具体算法过程：先构造一个长度为2^32的整数环（这个环被称作一致性Hash环）根据节点名称的Hash值（其分布范围为[0,2^32 - 1]）将缓存服务器阶段设置在这个Hash环上。然后根据需要缓存的数据的Key值计算得到Hash值（其分布范围也同样为[0,2^32 - 1]），然后在Hash环上顺时针查找举例这个KEY的hash值最近的缓存服务器节点，完成KEY到服务器的Hash映射查找。
优化策略：将每台物理服务器虚拟为一组虚拟缓存服务器，将虚拟服务器的Hash值放置在Hash环上，key在换上先找到虚拟服务器节点，再得到物理服务器的信息。
一台物理服务器设置多少个虚拟服务器节点合适呢？经验值：150。
一致性hash算法提出了在动态变化的Cache环境中，判定哈希算法好坏的四个定义：
1、平衡性(Balance)：平衡性是指哈希的结果能够尽可能分布到所有的缓冲中去，这样可以使得所有的缓冲空间都得到利用。很多哈希算法都能够满足这一条件。
2、单调性(Monotonicity)：单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中，又有新的缓冲加入到系统中。哈希的结果应能够保证原有已分配的内容可以被映射到原有的或者新的缓冲中去。 
3、分散性(Spread)：(即不一致)在分布式环境中，终端有可能看不到所有的缓冲，而是只能看到其中的一部分。当终端希望通过哈希过程将内容映射到缓冲上时，由于不同终端所见的缓冲范围有可能不同，从而导致哈希的结果不一致，最终的结果是相同的内容被不同的终端映射到不同的缓冲区中。这种情况显然是应该避免的，因为它导致相同内容被存储到不同缓冲中去，降低了系统存储的效率。
4、负载(Load)：负载问题实际上是从另一个角度看待分散性问题。既然不同的终端可能将相同的内容映射到不同的缓冲区中，那么对于一个特定的缓冲区而言，也可能被不同的用户映射为不同 的内容。与分散性一样，这种情况也是应当避免的，因此好的哈希算法应能够尽量降低缓冲的负荷。

13. 网络安全

1. XSS攻击
跨站点脚本攻击(Cross Site Script)，指黑客通过篡改网页，注入恶意的HTML脚本，在用户浏览网页时，控制用户浏览器进行恶意操作的一种攻击方式。
防范手段：消毒（XSS攻击者一般都是通过在请求中嵌入恶意脚本大道攻击的目的，这些脚本是一般用户输入中不使用的，如果进行过滤和消毒处理，即对某些html危险字符转移，如“>”转译为“& gt;”）;HttpOnly(防止XSS攻击者窃取Cookie).
2. 注入攻击：SQL注入和OS注入
SQL防范：预编译语句PreparedStatement; ORM；避免密码明文存放；处理好相应的异常。
3. CSRF（Cross Site Request Forgery，跨站点请求伪造）。听起来与XSS有点相似，事实上两者区别很大，XSS利用的是站内的信任用户，而CSRF则是通过伪装来自受信任用户的请求来利用受信任的网站。
防范：httpOnly;增加token;通过Referer识别。
4. 文件上传漏洞
5. DDos攻击

14. 加密技术

摘要加密：MD5, SHA
对称加密：DES算法，RC算法， AES
非对称加密：RSA
非对称加密技术通常用在信息安全传输，数字签名等场合。
HTTPS传输中浏览器使用的数字证书实质上是经过权威机构认证的非对称加密的公钥。

15. 流控（流量控制）

流量丢弃
通过单机内存队列来进行有限的等待，直接丢弃用户请求的处理方式显得简单而粗暴，并且如果是I/O密集型应用（包括网络I/O和磁盘I/O），瓶颈一般不再CPU和内存。因此，适当的等待，既能够替身用户体验，又能够提高资源利用率。
通过分布式消息队列来将用户的请求异步化。

16.序列化

序列化技术：
Serializable，序列化是将对象状态转换为可保持或传输的形式的过程。 序列化的补集是反序列化，后者将流转换为对象。 这两个过程一起保证数据易于存储和传输。
实现分布式的时候，需要将一个对象从Server分发给client。通过网络TCP，建立Socket，传输一个对象，就需要将对象转换成一段字节流，即对象的序列化。同时，也要求可以从这段字节流，创建出对应的对象出来。
---
java Serializable存储的文件内容：
当前类描述   
当前类属性描述 
超类描述
超类属性描述(如果超类还有超类，则依次递归)
超类属性值描述
子类属性值描述
---
序列化框架
（1）Java Serializable
java序列化主要是为了跨平台，实现对象的一致性，可在不同的平台上，保持自己原有的属性和方法不变
Serializable方法： writeObject()  readObject()
缺点：
1.无法跨语言。这应该是java序列化最致命的问题了。由于java序列化是java内部私有的协议，其他语言不支持，导致别的语言无法反序列化，这严重阻碍了它的应用。
2.序列后的码流太大。java序列化的大小是二进制编码的5倍多！
3.序列化性能太低。java序列化的性能只有二进制编码的6.17倍，可见java序列化性能实在太差了。
（2）Kryo是一个快速高效的Java序列化框架，旨在提供快速、高效和易用的API。无论文件、数据库或网络数据Kryo都可以随时完成序列化。Kryo还可以执行自动深拷贝（克隆）、浅拷贝（克隆）。这是对象到对象的直接拷贝，非对象->字节->对象的拷贝。
（3）Protobuf是google开源的项目，全称 Google Protocol Buffers.特点：
1.结构化数据存储格式（xml,json等）
2.高性能编解码技术
3.语言和平台无关，扩展性好
4.支持java,C++,Python三种语言。
（4）Thrift源于faceBook，2007年facebook将Thrift做为一个开源项目交给了apache基金会。特点：
1.Thrift支持多种语言（C++,C#,Cocoa,Erlag,Haskell,java,Ocami,Perl,PHP,Python,Ruby,和SmallTalk）
2.Thrift适用了组建大型数据交换及存储工具，对于大型系统中的内部数据传输，相对于Json和xml在性能上和传输大小上都有明显的优势。
3.Thrift支持三种比较典型的编码方式。（通用二进制编码，压缩二进制编码，优化的可选字段压缩编解码）
（5）Hessian
Hessian 是由 caucho 提供的一个基于 binary-RPC 实现的远程通讯 library