Keen的博客

记录所思、所想、所遇

欢迎来到我的个人站~


后台服务架构课程笔记

后台服务模型特点


登录、资料

例如好友分组基本协议:上传、下载,分组信息。协议安全性、移植性,校验问题,可能丢失分组。
开发、运维、扩展调整,例如聊天记录占用磁盘
预估容量和扩容速度,扩容容灾演练

运算量:好友列表本地排序
新老版本维护:好友分组多个版本,第一个版本上传下载,第二个版本单条新增删除等,灰度发布
安全性:协议安全(串改数据),外网服务器做转包,内网服务器做逻辑。
容灾:多数据备份
过载、其他攻击:登录态,防拉取所有数据

架构目标:(源于需求)用户数、用户功能性、容量、性能(好友印象数据不在登录一次性拉取下来,实际查看的时候拉取,并用时间戳用缓存)、运维运营(賍词过滤,考虑性能化异步删除操作)、竞争对手(优先级需求)
架构评估:满足需求、简单(简单技术做开发,例如单进程分布式)、可靠性(能支撑3~5年等)、扩展性好、安全、可运维运营(运营的重要性)
架构的演变性(需求、软件技术、硬件-x64或内存限制或磁盘读写能力等)

每秒2w请求量

后台进程间常用架构

interface-server结构(环形结构):

外部服务器 ——> 接口机 ——> process server1、process server2

优势:扩容方便、内部结构对外透明、统计收集、过载统一处理
缺点:
一般出问题(机器、网络、进程),所有的地方,都有单点故障。

问题解决:
对于一个接口机,可以搞多个并行避免单点
某个内部服务器出现问题,告知接口机,不要经过该机器
容灾,某个服务器出现问题,做服务器切换(重要业务秒级切换,实时;不重要的就做重启切换接入;非常不重要的,只做数据容灾)

回包不经过接口机:效率考虑,否则接口机请求量翻倍


processServer如何划分:业务特点(group划分,轻重分离,比如小号段更活跃、连号8更活跃。比如某些server处理某些号段,其他处理另一些号段,比如mod 10等,分配给不同server。)、扩展性、读写分离(写频繁会导致读抖动)

interface-server结构(星型结构):
外部服务器 ——> 结构机 ——> process server1
                     ——> process server2

优势:无单点故障,方便哪台机器问题,直接通知interface

进程内架构的分层模型

网络接入层(tcp、udp) ——> 应用协议层(多数据打包) ——> 逻辑处理层(数据逻辑处理) ——> Cache缓存层
                                                                             ——> Data数据层

网络接入层

选择tcp、udp?
qq登录服务器转包
独立接入(例如qq图像,如果用登录服务器,会影响登录。所以登录服务器只处理时间戳等)
udp:小数据量,方便分包的大数据
tcp短连接:大数据量(web拉图片、文字等)
tcp长连接:大数据量,心跳的维护(客户端每隔一段时间发一个hello包给服务器)

udp:可以集成18w,tcp:可以集成12w,所以qq登录服务器用udp

并发服务器:
用非阻塞套接字
大数据量一般选epoll,不会导致性能下降《UNIX网络编程。卷1.套接字联网API》-30章
IO效率不要随FD数增加而线性下降

接入通用模型:SvrFramework

UDP分包逻辑:丢包率为10%,客户端做3次重发逻辑。数据包越大丢掉可能性越大,所以分包(成功率会大大提升)。例如10k,每个发1k,分成10个包
如何分包:
nextuin、nextid
frompos + count(buffer)
filelist + leftlist(文件)
分字段
内外有别(内网服务器,一个udp发过去,丢包率很低,只要不超过udp的缓冲区65k)

应用协议层

协议怎么设计:
包头校验(开始标记) + 包头(整个包长度 + 操作命令 + 包序列号) + body(要查询的号码 + 查询的标记位) + 包尾(包尾校验,结束标记)

STX + 包总长 + 包头消息头1、2、3、...[CS命令号、seq(包总数校验)、客户ip和端口、外部ip端口、接口机ip端口、其他] + 消息体 + ETX

协议层作用:协议结构(网络字节序)和内存结构(主机字节序)的互转,Encode和Decode
切忌:二进制协议和缓存结构用同一个结构体定义,比如memcpy,在新增字段后,更有问题

逻辑层

第一种异步方式:session带了很多信息,不能做超时处理
第二种同步方式:即时,一般fork/预fork方式,多进程;不需要各个步骤的协议支持(无需带印象信息给各个服务);数据量不限;效率差;能处理超时;实现简单
第三种Session池+状态机:并发能力强;能处理超时;复杂的session

Cache层

原因:满足不了读的要求。但是能不用就不要用,防止数据不一致性。

SSD的硬盘,MYSQL的性能已经能满足了,可以无需cache

Cache资源比较珍贵,部分字段全Cache(比如名片业务:姓名和性别),或者部分用户全Cache+淘汰机制(比如游戏中,登录的在Cache,没登录在存储中)。

常用Cache模型:
ttc、memcached、redis、nosql(热门)
索引定位:直接定位(索引和内容分离)、hash定位(索引和内容合并)

即通采用hash,pos = key(QQUIN) mod 最大素数

cache的监控告警和cache扩容

Data层

关注存储性能

分清是计算型、存储型、综合型

性能指标:内存,硬盘,SSD(尽量硬盘的使用量不要超过50%,否则随机存储能力极度下降)

索引定位:DBMS(Mysql、tfs)、file存储

如果 把Cache数据回写到Data:
比较好的性能是,遍历Data,看Cache里有没有,有则写,没有就不写

打赏一个呗

取消

感谢您的支持,我会继续努力的!

扫码支持
扫码支持
扫码打赏,你说多少就多少