游戏服务端并发的问题是什么情况？

需求：扩容和容灾在全区分线模型下，游戏玩家可以随便选择任何一个服务器登录，自己的帐号数据都可以提取出来玩。这种显然比每个服务器重新“练”一个号要省事的多。而且这样也可以和朋友们约定去一个负载较低的服务器一起玩，而不用苦苦等待某一个特定的服务器变得空闲。然而，这些好处所需要付出的代价，是在存储层的分布式设计。这种设计有一个最需要解决的问题，就是游戏服务器系统的扩容和容灾。从模型上说，扩容是加入新的服务器，容灾是减掉失效的服务器。这两个操作在无状态的服务器进程上操作，都只是更新一下连接配置表，然后重启一下即可。但是，由于游戏存在大量的状态，包括运行时内存中的状态，以及持久化的存储状态，这就让扩容和容灾需要更多的处理才能成功。最普通的情况下，在扩容和容灾的时候，首先需要通知所有玩家下线，把内存中的状态数据写入持久化数据进程；然后根据需要的配置，把持久化数据重新“搬迁”到新的变化后的服务器上。——如果一个游戏有几千万用户，这样的数据搬迁将会耗时非常长，玩家也被迫等待很长的时间才能重新登录游戏。所以在这种模型下，对于数据存储的设计是最关键的地方。分区分服的关系型数据库我们常常会使用MySQL这种关系型数据库来存放游戏数据。由于SQL能够表述非常复杂的数据操作，这对于游戏数据的一些后期处理有非常好的支持：如客服需要发奖励，需要撤销某些错误的运营数据，需要封停某些特征的玩家……但是，分布式数据库也是最难做分布的。一般来说我们都需要通过某一主键字段做分库和分表；而另外一些如唯一关键字等数据，就需要一些技巧来处理。

系统用户业务主角和涉众三者的关系？答：主角又称参与者，官方定义是：在系统之外与系统交互的人或事。所以要找到参与者，首先要分清楚系统的边界，即系统之外是哪里。可以通过两个问题来找到这个边界：

   1、 谁对系统有着明确的目标和要求并且主动发出动作（系统外部）？

   2、系统是为谁服务的（系统内部）？

   主角不一定是人，可以是发出启动一个用例动作的任何事物，如计算机系统，计时器，传感器等...

   主角与涉众的关系：涉众是与要建设的这个系统有利益相关的一切人和事，主角是涉众代表。

  主角与用户关系：用户是系统的使用者，是主角的实例。

  主角与角色的关系：角色是主角的职责，角色是将众多参与者职责中抽象出相同的那一部分，将其命名而形成一个角色。角色一般适用于概念阶段的模型里面，以表达业务的逻辑理解。

打开CSDN APP，看更多技术内容

UML（thinking in uml 学习）--参与者和业务工人和涉众

占位 哈哈哈哈

继续访问

【数据库系统】第三讲 关系模型的基本概念

3.1 关系模型概述 1、关系模型的提出 2、关系模型的研究内容 一个关系就是一个Table 关系模型就是处理Table的，由三部分组成： 描述DB各种数据的基本结构形式(Table/Relation) 描述Table与Table之间所可能发生的各种操作(关系运算) 描述这些操作所应遵循的约束条件(完整性约束) 简单的说，即Table如何描述，有哪些操作、结果是什么、有哪些约束等 3、关系模型...

继续访问

Actor模型学习

最近看到了一篇写的贼好的blog，讲的完全详细，看得出来笔者的功力，所以赶紧转载过来，最下面有原文的地址。 大家一起共勉！ 传统的游戏服务器要么是单线程要么是多线程，过去几十年里CPU一直遵循摩尔定律发展，带来的结果是单核频率越来越高。而近几年摩尔定义在CPU上已然失效，为什么呢？ 大于在2003年左右，计算机的核心特性经历了一个重要的变化，处理器的速度达到了一个顶点。在接下来近15年里，时钟...

继续访问

Actor模型概念

转载自：https://blog.csdn.net/u014659211/article/details/63686965 从实习到现在，一直在做Unity相关的业务，不知不觉中感觉已经不在关注服务器相关的技术了。一次偶然的机会再腾讯的gad平台上观看了云风在15年在腾讯做的skynet讲座（http://gad.qq.com/content/coursedetail/467），skynet是用...

继续访问

深入解析actor 模型（一)： actor 介绍及在游戏行业应用

1 介绍 1.1 什么是actor 对于刚接触actor的我，第一感觉就像redis一样，每个actor就是一个redis 实例，都有自己消息队列，actor相互通信通过将消息发给对方，消息发送进对方的消息队列，等待对方线程处理。来看看我们之前做项目的痛点。 游戏服务器通常分为多个服，每个服上有多个玩家。假设玩家与玩家数据交互操作，这时怎么避免数据竞争？两种解决方案： 1、将数据写入redis 首先redis效率高，也是单线程模型，不存在数据竞争，但是也有它的不足之处，操作redis 会受网络影响

继续访问

java actor akka_如何使用Akka actor处理Java期货

我在Java Web应用程序中有一个分层架构. UI层只是Java,服务是类型化的Akka actor,外部服务调用(WS,DB等)包含在Hystrix命令中.UI调用服务,服务返回Akka未来.这是Akka的未来,因为我希望使用Akka期货提供的onComplete和onFailure回调来简化UI编码.然后,该服务创建执行某些映射等的未来,并将调用包装回返回Java未来的HystrixComm...

继续访问

Actor模型

传统的游戏服务器要么是单线程要么是多线程，过去几十年里CPU一直遵循摩尔定律发展，带来的结果是单核频率越来越高。而近几年摩尔定义在CPU上已然失效，为什么呢？ 大于在2003年左右，计算机的核心特性经历了一个重要的变化，处理器的速度达到了一个顶点。在接下来近15年里，时钟速度是呈线性增长的，而不会像以前那样以指数级的速度增长。 由于CPU的工艺制程和发热稳定性之间难以取舍，取而代之...

继续访问

actor-kotlin

actor-kotlin Java动态伪装工具，能够用伪装接口代理真实对象。(The Java dynamic camouflage tool can use the camouflage interface to proxy real objects.) 纯Kotlin开发，使用简单但功能强大，可用于组件化开发或插件化项目开发。 Android Demo: https://github.com/xuehuiniaoyu/actor-demo implementation 'io.github.xuehui

继续访问

天天酷跑多态

package Tianpublic class Actor{ String namePet petpackage Tianpublic final class Bear extends Pet { public void run(){ System.out.println("我是雄二，我喜欢蜂蜜")} } ...

继续访问

并发模型值Actor和CSP

CSP的是(CSP)的缩写，翻译成中文是顺序通信进程，简称CSP的核心思想是多个线程之间通过Channel来通信，对应到golang中的chan结构，对应到Python中是QueueGo语言的CSP模型是由协程Goroutine与通道ChannelGo协程goroutine是一种轻量线程，它不是操作系统的线程，而是将一个操作系统线程分段使用，通过调度器实现协作式调度。是一种绿色线程，微线程，它与Coroutine协程也有区别，能够在发现堵塞后启动新的微线程。通道channel类似Unix的Pipe。....

继续访问

Actor模型和CSP模型的区别

Akka/Erlang的actor模型与Go语言的协程Goroutine与通道Channel代表的CSP(Communicating Sequential Processes)模型有什么区别呢？ 首先这两者都是并发模型的解决方案，我们看看Actor和Channel这两个方案的不同： Actor模型 在Actor模型中，主角是Actor，类似一种worker，Actor彼此之间直接...

继续访问

Actor模式初步入门

Actor模型概念 Actor模型为并行而生，简单说是未解决高并发的一种编程思路。在Actor模型中，主角是Actor，类似一种worker，Actor彼此之间直接发送消息，不需要经过什么中介，消息是异步发送和处理的。在Actor模式中，“一切皆是Actor”，所有逻辑或者模块均别看做Actor，通过不同Actor之间的消息传递实现模块之间的通信和交互。Actor模型描述了一...

继续访问

并行编程模型之Actor/CSP/PGAS

并行编程模型之Actor/CSP/PGASActor1.背景2. 简介3.actor组成ActorMailbox邮箱behavior行为4.优势无锁异步隔离容错分布式5.劣势6.实践素数计算CSP1.简介2.CSP与go语言2.1 组成2.2Goroutine调度器3.Actor模型和CSP模型的区别PGAS1.简介2.实现 Actor 1.背景   处理并发问题就是如何保证共享数据的一致性和正确性，一般来说有两种策略用来在并发线程中进行通信：共享数据和消息传递。   熟悉c和java并发编程的都会比较熟悉

继续访问

go Actor模型和CSP模型的区别

Actor模型和CSP模型的区别 Akka/Erlang的actor模型与Go语言的协程Goroutine与通道Channel代表的CSP(Communicating Sequential Processes)模型有什么区别呢？ 首先这两者都是并发模型的解决方案，我们看看Actor和Channel这两个方案的不同： Actor模型 在Actor模型中，主角是Actor，类似一种worker，Actor彼此之间直接发送消息，不需要经过什么中介，消息是异步发送和处理的 Actor.

继续访问

控制`Actor`朝向,运动 Learn Unreal Engine (with C++)

控制`Actor`的朝向,以及

前段时间在golang-China读到这个贴：

个人觉得golang十分适合进行网游服务器端开发，写下这篇文章总结一下。

从网游的角度看：

要成功的运营一款网游，很大程度上依赖于玩家自发形成的社区。只有玩家自发形成一个稳定的生态系统，游戏才能持续下去，避免鬼城的出现。而这就需要多次大量导入用户，在同时在线用户量达到某个临界点的时候，才有可能完成。因此，多人同时在线十分有必要。

再来看网游的常见玩法，除了排行榜这类统计和数据汇总的功能外，基本没有需要大量CPU时间的应用。以前的项目里，即时战斗产生的各种伤害计算对CPU的消耗也不大。玩家要完成一次操作，需要通过客户端-服务器端-客户端这样一个来回，为了获得高响应速度，满足玩家体验，服务器端的处理也不能占用太多时间。所以，每次请求对应的CPU占用是比较小的。

网游的IO主要分两个方面，一个是网络IO，一个是磁盘IO。网络IO方面，可以分成美术资源的IO和游戏逻辑指令的IO，这里主要分析游戏逻辑的IO。游戏逻辑的IO跟CPU占用的情况相似，每次请求的字节数很小，但由于多人同时在线，因此并发数相当高。另外，地图信息的广播也会带来比较频繁的网络通信。磁盘IO方面，主要是游戏数据的保存。采用不同的数据库，会有比较大的区别。以前的项目里，就经历了从MySQL转向MongoDB这种内存数据库的过程，磁盘IO不再是瓶颈。总体来说，还是用内存做一级缓冲，避免大量小数据块读写的方案。

针对网游的这些特点，golang的语言特性十分适合开发游戏服务器端。

首先，go语言提供goroutine机制作为原生的并发机制。每个goroutine所需的内存很少，实际应用中可以启动大量的goroutine对并发连接进行响应。goroutine与gevent中的greenlet很相像，遇到IO阻塞的时候，调度器就会自动切换到另一个goroutine执行，保证CPU不会因为IO而发生等待。而goroutine与gevent相比，没有了python底层的GIL限制，就不需要利用多进程来榨取多核机器的性能了。通过设置最大线程数，可以控制go所启动的线程，每个线程执行一个goroutine，让CPU满负载运行。

同时，go语言为goroutine提供了独到的通信机制channel。channel发生读写的时候，也会挂起当前操作channel的goroutine，是一种同步阻塞通信。这样既达到了通信的目的，又实现同步，用CSP模型的观点看，并发模型就是通过一组进程和进程间的事件触发解决任务的。虽然说，主流的编程语言之间，只要是图灵完备的，他们就都能实现相同的功能。但go语言提供的这种协程间通信机制，十分优雅地揭示了协程通信的本质，避免了以往锁的显式使用带给程序员的心理负担，确是一大优势。进行网游开发的程序员，可以将游戏逻辑按照单线程阻塞式的写，不需要额外考虑线程调度的问题，以及线程间数据依赖的问题。因为，线程间的channel通信，已经表达了线程间的数据依赖关系了，而go的调度器会给予妥善的处理。

另外，go语言提供的gc机制，以及对指针的保护式使用，可以大大减轻程序员的开发压力，提高开发效率。

展望未来，我期待go语言社区能够提供更多的goroutine间的隔离机制。个人十分推崇erlang社区的脆崩哲学，推动应用发生预期外行为时，尽早崩溃，再fork出新进程处理新的请求。对于协程机制，需要由程序员保证执行的函数不会发生死循环，导致线程卡死。如果能够定制goroutine所执行函数的最大CPU执行时间，及所能使用的最大内存空间，对于提升系统的鲁棒性，大有裨益。

---