思考：以卖票为例子思考Actor模型(3种卖票方案对比)
作者：互联网
假如票有100张，多线程卖票，如何保证并发 安全 呢?
1)常见思路（单体）
比如：保证 多线程对于票的修改是线程安全 的。 因此：需要加锁。在 每个线程修改的地方
synchronized(ticket){
// 检测票是否足够
// 足够则通知发货
}
思考：
这种其实类似于我们现在的游戏服务器架构，其实想想也是不错，只有一个进程，多个线程相互倒数据。
在卖票时，先以此ticket为锁，在事务退出前是不释放的，因此保证了线程安全。而且对于多个玩家的交互，是不错的。
2)actor模型
TicketActor： 票actor，维护票数，只有它有修改的权利。
PlayerActor：有多个，想要买票 ，先向TicketActor发起询问，TicketActor查询票是否足够，够了则通知下单。
思考：
感觉不错，而且很直接，可惜 我不熟悉actor模型，工作中也没用过，但是思路我是赞同的。
3)队列术
还有一种是，GameServer GlobalServer这种架构，公共的数据放GlobalServer上。 多个玩家连接着GameServer，发起rpc调用询问GlobalServer是否有票。GlobalServer进行决策回复能否卖票。
可见：队列术跟actor模型其实是一样的做法，在 多进程方案的话，需要用这种。
当然了可以单进程，多线程的方案，某个固定线程负责ticket的修改 。
其余线程负责业务逻辑处理也是可以，也是我们现在的做法，只不过有点混乱。
标签：卖票,Actor,GlobalServer,线程,actor,思考,ticket,多线程 来源： https://blog.csdn.net/themagickeyjianan/article/details/121048878