7月文章读后感

http://www.jianshu.com/p/37281543f506

而描述事物的有限状态机模型的元素由以下组成:

  • 状态(State):事物的状态,包括初始状态和所有事件触发后的状态
  • 事件(Event):触发状态变化或者保持原状态的事件
  • 行为或转换(Action/Transition):执行状态转换的过程
  • 检测器(Guard):检测某种状态要转换成另一种状态的条件是否满足

在demo中做了简单的状态机,我做的工作被这篇几个组成部分彻底包含了,这些还考虑了更多。

http://www.linkedkeeper.com/detail/blog.action?bid=190

讲京东京麦高可用框架的实现,

网关API这部分经过了几层缓冲和各种验证,

文章中说到,元数据获取性能是 API 网关的关键点,基于DB做是不可取的,即使分表分库也不够压力看的。

定时轮询对服务器压力大,MQ广播是一个方法,但只解决了数据同步的问题,数据缓存和数据库的一致性问题又增加了系统的复杂度,但又说读内存如果内存没有再一层一层请求,这种情况会有一致性的问题,至少会经过网络延迟级别的数据错误。

使用TCP长连接做会话层,为了支持断线重连接入层被拆分为session和channel,每次重连都会创建一个新的session,但channel再连接断开时不会立刻断开。传输层使用json作为通信协议。

使用令牌桶实现多维度流量控制。

自研了一套实时的,可靠的,异步的双向数据交换通道。

https://mp.weixin.qq.com/s/l1pnVc_E-Nz6Z27iC0G6GA

对于游戏服务端架构,最重要的三个部分就是,如何使用CPU、内存、网卡的设计:

内存架构:主要决定服务器如何使用内存,以最大化利用服务器端内存来提高承载量,降低服务延迟。

逻辑架构:设计如何使用进程、线程、协程这些对于CPU调度的方案。选择同步、异步等不同的编程模型,以提高服务器的稳定性和承载量。可以分区分服,也可以采用世界服的方式,将相同功能模块划分到不同的服务器来处理。

通信模式:决定使用何种方式通讯。基于游戏类型不同采用不同的通信模式,比如http,tcp,udp等。

说了一种线程模型,将收发线程和逻辑线程拆开,逻辑使用独立的线程,收发独立的线程,和我自己开发的那种逻辑和收发都在同一个线程的模型来说,好处在于支持逻辑线程有轻微的阻塞。

然后到了分布式,一般划分为gate,登录服务器,场景服务器,场景无关(世界聊天,贸易…),AI服务器,代理服务器,DB服务器等等。

https://mp.weixin.qq.com/s?__biz=MzI3MTQ1NzU2NA==&mid=2247483875&idx=1&sn=215a6d5965fbd578bf06b6c88496612f&chksm=eac0cd90ddb7448657df188a6c78777e66228cff592f61de2959867148a61a9005b80ab7b54f&scene=21#wechat_redirect

介绍王者荣耀的后台架构,前面并没有说匹配房间的过程是如何实现的;然后介绍王者荣耀使用UDP开发;

王者荣耀使用帧同步,服务端主要的工作就是转发消息。

http://wetest.qq.com/lab/view/320.html

腾讯做的WeTest,流量控制。

在做分布式限流的时候,很关键的一点是要将流量控制服务原子化,流量控制有两个信息,计数,计时。

并发量大的时候CAS锁的性能不高,这句话我是黑人问号的,难道不是硬件实现原子级别的CAS锁嘛??

原生的incr不能实现定时过期的问题,他们使用以秒为单位的时间作为key,然后使用内置的incr实现计时/计数功能。

然后如何实现定量呢,采用的方法是向管理中心请求一批额度,每次额度耗尽再上报再请求额度。

单机和全局控制同时开启,解决容灾问题。

然后机器之间时间不同计时计数就有问题,竟然还考虑了服务器获取了锁挂掉的极端情况。

发表评论

电子邮件地址不会被公开。 必填项已用*标注