关于游戏服务器是多线程还是单线程的讨论

最近做有关于游戏服务器用单线程的好还是多线程的好的讨论
有同学问：服务端逻辑全单线程的模型，为了避免查询离线玩家数据造成阻塞，除了启动服务器全部加载以外还有更好的办法吗？
同学B： 单线程逻辑模型也属于很常用。逻辑本身不容易出问题。
IO得全部分出去。
同学B： 用异步加载事件。数据加载完成后。再重新把任务排入单线程任务队列。
同学C： 各种活动NPC打完就要从场景消失  战斗线程和场景线程分不开
同学C： 场景线程依赖战斗的结果
同学C： 战斗的结果会影响NPC在场景的动态显示
同学C： 然后还有交易，还是和端游一样的在线即时交易
同学C： 用多线程就容易刷物品
同学C： 用多线程就容易刷物品
同学C： 我最开始想的是  交易的时候将交易的物品放到第三方线程去搞，但是如果玩家中途点了取消或者下线或者各种状态  你要将道具返还给玩家
同学C： 但是在这期间 玩家可能又会操作背包
同学D： 交易的时候 被交易的东西是锁住的
同学C： 你说的被锁住的  是个什么概念，是不能进行其他任何操作吗
同学E： 交易的时候可以不用锁。做线程排队
同学B: 我们以前的交易是和WOW完全一样的
           放上去的东西 交易成功/失败前  在背包里面不能移动、丢弃
然后玩家一方点击移动  也马上取消整个交易    
同学E： 掉取消 也 让他进入线程排队啊
同学B: 回滚没必要思考那么复杂
可以设计交易成功之前都是副本操作
专门用一个交易容器来存交易过程中的这些临时对象、状态
同学F： 涉及到多玩家的交互要么加锁，要么抛到各自的线程处理，然后用回调。
比如我买你的东西，在我这里扣了钱之后，就发个请求到你的线程扣除物品，扣除结果再回调我这边。决定是失败返回扣的钱给我，还是成功给我加物品。
这种效率是最高的，不用锁。
同学C： 我说的交易不是摆摊
同学B： 这种架构会搞死程序员，这么做完了 后面维护期也户i被搞死
同学M： 你们怎么区分的单线程还是多线程
想改为单线程 就不用考虑阻塞了
同学B： 接收请求多线程
处理按逻辑分到不同队列后单线程
某些特定场景、活动再单开线程
总之就是接收多线程 处理逻辑单线程 偶尔有多线程的地方自己维护锁 然后用了OrderedThreadPoolExecutor