账号：jackma
支持！

@bthulu 看起来就是写不依赖读，或者说写需要的读状态可以是旧数据（只需完整，无需最新）。那么单纯的将 Device 变为不可变就行。ConcurrentDictionary 单纯的读写本身是原子的，查了一下，不可变的线程安全 C# 与 Java 是一致的。

如果更新的时候不看原来的数据，且 [多个监控线程每隔 100 毫秒读取一次所有设备状态, 并根据设备状态执行一次或多次耗时较长的异步操作] 这个过程中数据变化了也没关系的话，可以考虑直接将 Device 变为不可变（所有字段都 readonly)。

C# 不是特别熟了，devices 本身读写是线程安全的，里面的 device 只要每次更新的时候是替换一个新的不可变对象，这在 java 中是线程安全的。

几十个字段的拷贝，应该也还好。

求推荐一些 flutter 开发的较重型的 app 体验下。

接触过的几个链上项目都是这么做的，生态，可控度都不错，主要是用户切换成本低，和 tg 共享生态也即意味着和其他链项目共享用户生态。

区块链惯用方案不应该是：telegram 客户端改，群组聊天全部走 tg ，定制客户端增加钱包，社群，资源等相关页面即可啊。

Kotlin + Spring Boot

前面有人说 PHP 一个接口光写十分钟吧

自己平时做的 CRUD 接口，一个系列增删改查一般总共十分钟不到吧。
Flyway 定义数据库表结构
定义参数结构，通过注解做参数校验（一堆 PHP 不做这个事，有但是不多）
定义个
写 Controler ，写 Service ，MyBatis Plus 一把梭。
对了，带上 Spring Doc 注解，完事后，直接生成文档页面，还可以文档页面直接测试接口。

中间会有些手误啥的错误，强大的类型，包括 MP 都是泛型关联数据库字段，大部分错误编译期就能看的非常清楚。
参考老代码也是一目了然，类型是最权威的注释，也是最权威的代码脉络总纲。

带上测试，15-30 分钟差不多全部搞完吧。

PHP 搞数据库，绝大部分字符串拼接一把梭，搞出问题来了在哪里 Debug 个半天，看着让人想笑，一堆说自己快的人搞出有注入风险的代码。

有些搞法所谓的快，是不是真的比人快先不说，出来的东西，我是懒得维护的，后期找起来就是天书。

对了，后面部分接口想做改造，加个缓存，加个读写分离啥的，你们猜要多久，要改动多少？

Kotlin 语法既强大，又简洁，还简单。建议去试试。

一般按分成合作的渠道方，会要求产品方接入指定的支付通道，也就是所有的流水是先进入到渠道方户，然后按期按比例结算给产品方。这样的话，充值数据双方都是很清晰的。
至于切支付这种骚操作，各家反正都有防。App Store Google Play 这种就是审核+下架+封账号教做人。至于国内的小米华为这种啥的，和前面 2 种有本质区别，这种渠道都是严格的指定量，上这种渠道很不划算，即使有自然量也是产品方的品牌效应。我的理解就是，上这种渠道一般都是因为渠道会保证提供一定的量。如果被发现后期切支付，渠道方只需终止合作不再提供量就行了。
重点产品合作方一般都会定期复查一下的。
个人认为，有流量合作的，不要切支付，坏口碑，以后难找合作。
Google Play App Store 这种，切支付必然夹带马甲包，操作成本也很高，省下来的 28% 左右的利润能否支撑这个操作成本需要自己衡量。
以上有一个例外，就是国内付费游戏，又无版号，这种如果非要违法上，只能切了。

跳板机上没 nc 的话，可以直接先在跳板机上开个隧道
ssh -Nfg -L 3306:127.0.0.1:3306 目标机
然后在本机上执行
ssh -Nfg -L 3306:127.0.0.1:3306 跳板机
这样访问本机的 3306 会先通过隧道到跳板机的 3306 然后再通过隧道至目标机的 3306

C++ 的服务端吗？说个非 C++ 的方式，填业务逻辑的地方是框架预留的地方，都做了异常的检测。服务挂掉的时候框架会提供指定的异常回调处理。一般情况下在这里记录日志加回写数据。半年的研发周期本身就应该让宕机的概率变的很低。挂掉还有机会回写将数据丢失的可能性进一步降低（当然，要保证回调里面不再或几乎不会出现异常）。
但是，这样还是不能解决数据一致性问题，比如修改数据一半挂掉。这种情况下回写的数据是不完整的。这种只能通过业务逻辑中的日志来记录。非极端情况下是能将玩家数据恢复到之前一致的。
以前特别纠结这种问题，总想为什么没有既能完全保证数据一致性，性能又好，心智包袱又小的方案，让写业务逻辑的时候无脑一点。现在想想真的太难，老老实实做好日志记录，关键数据一致性问题能通过日志追踪复原到比较理想的状态也差不多了。

就是 mysql 这种，ACID 不开串行异常级别，一致性也不能支撑完全的无脑的开发。
比如扣减余额，转账这种。默认可重复读级别并不能解决并发的问题。只要允许 2 个事务一起操作该数据，一样余额能成负。最终还是需要额外处理。

接过大量 SDK，也开发过一些。建议所谓测试模式正式模式，都做到生成环境中去。

正规一点的 SDK 常见的做法是：为客户分配参数，然后客户的应用默认是 Test mode.

客户正常接入（接入过程中会有很多垃圾数据脏数据），等到正式接入完成，你们再后台验收，查看关键接口调用与数据是否正常，验收正常，将 Test mode 修改为正式模式。


容易出错的地方，不要吝啬，多打日志，客户多了，什么样的程序员你都会见到的。

开发者账号有区域之分吗？结算不都是走美元吗？个人的话，提供双币信用卡就行了啊。

直接申请开发者账号。开发者区域和应用发布区域没啥关系啊。
无论怎么申请的开发者，都可以发布全球区吧，只要符合当地规定就行。比如如果发布时要选大陆，付费游戏就需要提供版号。

@gantleman
还有，你说 [普通程序员用演员模型加数据库写的缓存服务不可能比 redis 更快]
当然，特指场景服务，多少人同屏本身服务端压力就是场景服务
场景服务一般做法是，状态直接在内存中，这个内存是 Actor 的 state，Actor 可以是一个完整的小场景，亦可以是一个大场景的一个区域，根据实际情况划分。
该区域类的玩家操作直接在该 Actor 中处理，状态就在这个 Actor 内存中，而且就是原生的数据结构。各种技能的计算就像在客户端写顺序代码一样，数据会有策略落地，但是逻辑都是在内存中完成，只有加载场景才有读的动作。

并不是你想的那种 CURD，一个请求过来从数据库或者其他缓存中拿一堆丢失了结构的数据，一顿操作然后再回写数据。

@gantleman 前面已经举例了，场景中玩家释放范围技能，技能还分各种类型，与玩家当前的 Buffer 息息相关。想想你状态都放 Redis 逻辑怎么写？ PVP 的时候，血量，Buffer，技能类型的触发逻辑还是要非常严谨的。2 人一起释放技能攻击第三方，第一个技能攻击到受击者触发一个被动 Buffer 并进入 CD，第二个技能攻击到受击者，但是被动已经 CD，不会触发。按你上面的状态都丢 Redis，先不说你那个取范围技能的所有受击方靠不靠谱，场景角色上挂的 Buffer 血量等等相关的数据不要太多，2 个技能，你要保证被动只触发一次都麻烦的很。这还只是众多技能中非常常见的一些需求。

前面说的都是场景相关的功能，场景，Scene 。什么九宫格，十字链表，相位啥的，都是应用到场景服务上的。
养成玩法就不说了，谁跟你说场景服务是每个玩家每种功能创建服务？创建 Actor 永远都是把相关的放一起，不怎么相关的分离开来的原则。 [连 Actor 的拆分都是要考虑粒度的]

太真实了。。。

说的是 POJO 麻烦，还是 Dto 与 Vo 转换的麻烦？
POJO 嵌套可以用 lombok 嘛。
至于 Dto Vo 转换这种，MapStruct 了解一下。
https://github.com/mapstruct/mapstruct-examples
这里面的：mapstruct-mapping-with-cycles 、mapstruct-nested-bean-mappings 2 个例子应该是你感兴趣的。

在知乎上又看到了这篇文章。
多说几句，超大地图，AOI 这种，跟放不放 Redis 没啥关系。所谓的相位技术也这是场景分割的一种方式。数据不放 Redis 的原因是，场景中的计算本身就需要实时，放到 Redis 中还得要异步的读写，明明用了 Actor 模型将关联逻辑分割到一起降低了并发与同步的心智包袱，又引入一个外部缓存让计算变成异步的，带来的数据一致性的问题完全抵消了 Actor 模型的优势。大量的位置数据，AI，技能延时，技能范围伤害等实时的逻辑都依赖状态，这些状态放外部存储中逻辑写起来有多麻烦尚且不说，拆的这么细，性能风险很高。连 Actor 的拆分都是要考虑粒度的，状态提出去把场景服都搞成无状态实在不觉得收益在哪里（养成等玩法无状态倒是没啥问题）。
Actor 模型在游戏界中往往用 state full 的形式，场景不是简单的状态，而是 状态+计算。
像微软的
Orleans （ https://github.com/dotnet/orleans ）
与 EA 开源的
Orbit （ https://github.com/orbit/orbit ）
这种新型的 Virtual Actor 模型的框架，游戏场景的使用都是 state full 的形式。
redis 的优势，
集群，游戏已经场景逻辑上已经通过 Actor 分割了，用不上。Actor 分割出来的逻辑数据单元关联性要强的多了。
各种数据结构，性能有没有优势不说，放外部已经高了不少延时，最主要的是复杂点的数据，没法按场景服务计算式需要的结构，直接扔 Redis，最后必然带来一个转换的开销。
各种过期淘汰策略，这在场景服务中做完全没问题啊，业务逻辑中 timer 相关的东西多了去了，Redis 反而不够用。

示例中场景，交互性太弱了，角色与角色之间的交互太少，跟真实游戏的业务场景相差太大了啊

当然，说了这么多，都只是解决大场景，同场景的一些方式方法。
万人同屏这个不敢想，个人觉得，目前的硬件，最后无论用什么方式（除了 step lock ）做到了万人同屏的效果，
我估计实时性肯定无法让玩家能感受到正常的游戏体验。

游戏中的这种场景，一般都是不用 redis 的。如果考虑支持在线数高，还是偏向于数据直接放在场景服务的内存中。