目标：

        介绍一种后台服务架构的基本原则

        了解系统内不同进程之间的基本组织形式

        了解进程内的分层模型和每层的一些设计要素

---

后台服务模型特点：

        数据量多，并且不断增长

        运算量大

        可维护升级，但不能影响用户

        安全性要求高，容灾，过载，攻击

---

架构的目标：

        从何处出发想架构？

            架构源于需求：用户功能性，容量，性能，运维运营，竞争对手...

        如何衡量一个系统架构是否合适

            满足需求的，简单的，可靠的，扩展性好的，安全的，可运维运营的

        架构是一个演变的过程（需求演变和技术更新）

            技术更新：缓存，硬件磁盘等等

            需求更新：数据量越来越多。比如好友分组从开始的几个组->演变到几十个组，需要添加排序

---

后台进程间常用架构：

    Interface-server架构（环形）（中小型企业常在内网中使用）：

        外部请求接口->interface根据某种规则分发->ProcessServer上处理查找->返回给外部请求（批量拉取会经过多个ProcessServer）

        优点：内部结构对外透明，方便扩容调整，对于外部接口来说不需要知道有多少ProcessServer，只需要知道interface就行。

                   各司其职，屏蔽和外部系统的耦合

                   简化网络结构 

                   过载保护等统一处理

        缺点：单点故障（是指系统中一点失效，就会让整个系统无法运作的部件，换句话说，单点故障即会整体故障）

        单点的故障的解决方案：interface1出故障了，外部接口可以访问interface2，interface3。ProcessServer出故障了，可以interface过滤掉这块的请求，也可以对故障的ProcessServer进行瞬间的切换（我的理解就类似于redis里的哨兵）

        回包的时候为什么不经过Interface？

        答：如果请求量不是那么大的话可以经过Interface（方便统计），但是不经过interface的话，interface的数据处理量直接减少一半

        Server如何划分?

            1业务特点     2扩展性     3是否读写分离?(写频率)     4轻重分离：活跃用户与非活跃用户

    Interface-server架构（星形）：

进程内架构的分层模型：

网络接入层：TCP/UDP协议

        1 选择tcp/udp?        

            登录服务器主要进行时间戳的处理（什么时候更新的，更新了多少），头像如果采用登录服务器处理，会影响性能

        2 登录服务器装包

        3 独立接入--单用户请求流量

                udp：小数据量，方便分包的大数据    （采用udp大约支持18W人同时登录，tcp大约支持12W人，当网络差udp登录不上去换tcp）

                tcp短链接：大数据量                        

                tcp长链接：大数据量，心跳的维护

    并发服务器的选择：select与epoll

        高性能并发服务，用非阻塞套接字（异步，分布式）

        epoll支持超过1024个套接字

        IO效率不随FD数目增加而线性下降（epoll只与活跃数有关）

        ET与LT的区别（水平触发->一直告诉你这个套接字可读    边缘触发->把所有的缓冲区的数据读出来）    

        《UNIX网络编程.卷一，套接字联网API》->第30章 客户/服务器程序设计范式

    后台通用模型：SvrFramework（听不懂，先记下）    

        包含主循环的框架

        只需要指定本地地址，完成包处理函数即可

        调用SrvFrameworklnit指定绑定地址和注册回调函数

应用协议层：

        包头校验字段+数据长度+数据内容（操作命令号，包序列号等等）+包尾校验字段        

        应用协议层的作用：协议结构与内存结构的互转（切忌二进制协议和缓存结构用用一个结构体定义）

    UDP分包逻辑：

        为什么要分包？举例：客户端有3次重发逻辑，假设一个分组丢包率为10%

            方法1：直接发送10K数据  成功率86%

            方法2：分成10个包，每次发1K 成功率99%

        怎么分包?

            NextUin，NextID逻辑

            FromPos+count

            FilledLst+LeftLst

逻辑层：

        问题：好友服务和好友印象，是两个独立的后台服务。客户端需要一个请求修改qq好友印象，如何实现该逻辑？

        方案一：Session信息待在协议包里

                需要应用层协议支持，数据量不能太大（包中不但需要有好友信息，还要有好友印象）

                复杂度中

                不能处理超时（异步的 UDP转包的）

                只能处理简单session

        方案二：同步阻塞式处理

                采用即时fork/预fork方式，多进程处理

                不需要各步骤的协议支持

                数据量不限

                实现简单

                效率较差，能做超时处理

        方案三：session池+状态机机制

                并发能力强

                实现复杂

                需要超时机制

                能处理复杂session

        1.好友服务器给客户回包一个签名，还有印象服务器验证签名，判断好友关系

        2.同步好友服务数据给好友印象，本地验证

cache层：

data层：  

        了解业务是计算型，存储型还是综合型

        内存：读写几百万级别

        硬盘：顺序读写与存储量有关，随机读写一般250次

        SSD：随机读写一般2W次，与寿命相关。写入频率大，效率降低10倍

        注：最后一种如果每秒几千次读写，可以写在内存中。生成一个顺序流水log，通过流水log恢复