接入层session设计原则：
1、Session—读写请求使用的上下文对象，称之会话。
业务总有状态的：用户下单购买、登录状态、好友状态、消息发送情况等；
这些有状态的信息随用户操作变化。
单机环境下：
- 不存在session共享问题；
- 处理简单；
- session保存在内存；
- 高可用不能保证（进程挂掉、宕机、session丢失不可用）。
集群设计：
--session复制：
所有接入层服务器之间同步session数据；
每台接入服务器都保存用户全量的session数据；
用户只需访问一台机器，获取速度快；
高可用保障：宕机部分机器，没影响。
问题：
--适用于接入层集群较少，不适量大量上千台接入层服务器；
--大量session复制，占用服务器和网络资源；
--存储全量用户session，内存占用量太大，甚至有可能溢出；
大型设计：
session绑定：
根据用户请求(UIDMacimei等唯一标示)负载均衡到特定接入层服务务器；
部分网站使用；
高可用如何保障：单点问题、复制机制（master-slave）
多机设计：
客户端保持 session：
--session由服务端生成，存储到客户端；
--每次请求携带客户端session；
--服务端若有更新返回给客户端存储；
C/S：
--APPS：记录到Native中；
B/S:
--Web：记录到Cookie中。
缺点：
Web Cookie记录信息大小限制（如100KB）；
每次请求都要传输session：流量、性能受影响；
用户关闭、清理掉session，用户请求不正常；
优点：
方案简单，支持服务端的无缝伸缩；
方案可用性高；
较多网站使用；
Session高可用集群：
--接入层无状态化；
--统一的高可用session分布式读写服务器集群；
--状态分离：
接入层本身无状态；
session集群有状态：
分布式缓存（NoSQL—memcached/Redis, RDBMS—Mysql/MongoDB）
接入层安全性：
接入层是客户端和服务端的Interface；
数据安全重要性不言而喻；
保证数据安全性：连接通道加密、传输数据加密。
客户端与服务端建立安全信道—技术方案：
所有请求数据都加密，提高效率；使用对称加密算法；
对称加密密钥使用非对称加密算法经过两次协商确定；
安全信道的建立必须满足：
任何第三方无法伪造服务器；
在破解客户端代码的情况下，即使截获其他用户发送的加密请求也无法解密。
使用HTTPS：
数据安全的加密；
不推荐单向加密；使用双向加密（安全）
客户端证书
数据加密目的：
解决数据明文的问题；
即使截获也无法解密；
无法保证数据篡改；
如何保证数据正确性：
数据签名：双方约定规则签名（md5sum、其他）
过程：
- 客户端按照约定签名；
- 服务端收到数据，按照规则生成md5sum值；
- 和数据包里md5sum值比较是否一致；
- 一致说明没问题；不一致则说明被改
高可用接入层最佳实践：
模块与数据分离；
session绑定：每个session同步复制；