夏新 F9 ,6.2 元包邮,2000 毫安电仓,耳机电量连续使用 5 小时。
每天撸一管算不算是一种运动呢,排泄一下应该还是挺有用处的,雄性激素过旺导致我头发溢脂性脱发了,发际线快要变成 M 形状了。
我之前买了一个背包,结果用了一个月之后拉链坏掉了,觉得扔掉之后很可惜,然后我在网上买了十几米的拉链(几块钱包邮),自己一针一线的给换了,除了边角不好缝,其他的还好。花了 3 天时间缝完了,现在使用良好。
事务是基于链接的,也就是说一旦你开启了一个事务,并且希望接下来的调用使用同一个事务,那么就必须使用同一个链接,就必须要把这个链接保存到一个地方,让所有使用数据库的方法都能够以一种相同的方式获取一个链接。
在 Java 中可以使用 ThreadLocal 来保存线程安全的变量,在当前线程的执行过程中,获取到同一个链接实例。如果是异步的,那就必须要考虑到链接的创建与提交,也就是要明确在什么时候开始,什么时候结束,Spring 的注解实现基于 AOP 的拦截,在“同步方法”调用之前开启事务,调用之后结束事务,它在背后实现了我上面第一段说的那些内容。
所以在没有 ThreadLocal 可以使用的时候,你必须要将一个链接进行传递,比如将链接封装到一个 Context 结构中,设计出一套接口标准,让所有使用数据库的代码都遵循这一套接口。不仅如此,还需要考虑到“同步”与“异步”的使用同一个链接将会带来怎样的影响,因为协程本质上也是在一个线程上运行,当多个协程同时运行在不同的线程时,就需要考虑到并发问题,因此不太建议“异步”使用一个事务。我对 Go 不太熟悉,但是背后的逻辑应该是以上这些内容。
看情况
如果大多数情况令牌都足够充裕,第二种实际上是更好的做法,因为直接写了,相比第一种,少了一个读的操作。
如果大多数情况下令牌不够充裕,那么第二种相比第一种多了一个写的操作。
但是很显然,我们大概率无法提前得知哪种情况才是相对常见的,我个人的话会选择第一种。
你有没有想过,有时候可能并不是单纯的技术原因所导致的,而是一次又一次变形的需求?层层加码,而又没有时间回过头来梳理和重构,必定会导致这些问题。
吃褪黑素+1 ,不过第二天起床感觉有点怪怪的,就感觉大脑空白
如果我们的眼光只局限在技术层面,那么 DDD 对你而言有用的就是战术模式那一部分,也就是编码的那一部分。如果我们把眼光放高一些,着手解决整个产品研发生命周期的效率方面,或者 DDD 就能帮大忙。这不仅仅使我们工作更加轻松,更加快乐,也使得我们不会把时间浪费在一些经常反复出现并且很愚蠢的事情上面。当然这个愿望很美好,但是不一定每个人都想做得这么美好。
总的来说,DDD 分为两个部分,一个是技术实践的战术模式,一个是工程架构的战略模式。
其中,战术模式仅作为实现的部分参考,总结的是以面向对象范式编程语言的一些常用技巧与原则,提炼出了一些可以跟非技术人员沟通的构建单元,也就是你可以跟产品直接聊的一些东西,比如实体、值对象、仓库等等。
其实最重要的是战略模式,这部分也是大多数接触 DDD 的人觉得云雾缭绕的东西,看不见摸不着。团队规模小了,搞这些觉得繁琐,团队规模大了,面对已经成熟的 CRUD 基本上都有一套成熟的流程方案了。所以这个东西真正有价值的还是回归本质,解决软件核心中的复杂性。
首先你得是一个团队,否则的话一个人还搞什么 DDD 对吧?其次对团队里面的人也要有一定的要求,起码在沟通上,要明确价值。也就是说哪些信息对于不同岗位的人来说是明确的,是可以沟通的和达成共识的,哪些信息对开发或者产品来说就是废话,要把能够体现出真正用意的这部分提炼出来,在整个团队中进行传播和理解。
其次,有了高效的沟通和统一的理解以后,才能对同一个事物进行拓展(研发),需要在前者的基础之上,搭建一套能够迅速有效解决问题的工作流程,对产品进行高效的迭代。DDD 的战略部分就是基于前者,然后再结合一些准则和经验,帮助你如何解决更大规模的软件工程问题。
以上这些当然都是很美好的初衷,但是我个人认为,关键变量不在于每次迭代能否更进一步,而在于对人的管理,什么意思呢?人的不确定性才是最大的不确定性,人这个变量的影响范围如果能够控制住,培训也好,工作范围的划分也好,只要能够达到一种“柔性”的状态,终归会回归正轨。
说得有点多了,尽信书,不如无书,要有自己的思考。
nosql 大多都是分布式数据库,如果引入自增的这种特性,意味着每一次插入都需要协调维护一个计数器,这会引入额外的同步开销,因此最好是自己在应用层去维护这个计数器,而不是依靠数据库本身提供类似的功能。
语言用 C++是有优势,但是相比较之下,良好的架构更加重要,要兼顾到日常逻辑开发的便利性,如何权衡取决于公司的用人成本。用 Java 配合 Netty 已经足够承载绝大多数游戏类型了,并且招人也很方便。
游戏服务端一般是有状态的,而 web 开发大多数是无状态的,有状态就意味着容易出现单点事故,比如网络不可靠,机房出现故障,服务端宕机等等,因此就需要通过日志的方式来存储状态变更操作,尽量减少事故带来的影响。类似于 redis 的 AOF ,mysql 的 binlog 。
要知道大多数在线游戏后端主要是计算密集型的应用,跟 web 开发的区别之一就在于基本上所有的状态都会保存在进程内存中,目的就是尽量避免 IO 操作。数据库的作用仅仅只是用于存档落地,甚至简单的来讲都可以不要数据库,直接二进制文件也可以。比如我经常在开发调试的过程中将整个玩家对象序列化为一个 JSON 文本,特别方便用于测试的时候,设置各种玩家的快照还原。
还有很多关于游戏后端开发的知识要点,一次也说不完,比如线程模型,元数据(配置)管理,网络 IO ,二进制消息协议,GM 管理后台,第三方系统集成等等,是一个很庞大的内容。
值得庆幸的是,随着用户的爆炸增长,现代的服务部署以及运维都比以前要好上太多了,使用云服务和容器成本更低,更有保障,但一切的前提是要根据游戏类型选择合适的技术架构。
我用的阿里云的,223.5.5.5 、223.6.6.6 ,有没有大佬说一下优缺点?
如果你的表有几千万的数据,并且值是稀疏的,可枚举的,使用 int 会比 varchar 要少占用很多的存储空间,量变决定质变。
干嘛一定要刻意的去戒呢,想起来了就放下嘛,主要是怕想不起来,比如在一条腿上面系上一本书啥的。
如果是游戏,还需要出版号,否则不能进行收费,这个已经很久没有发了。
补充一下:
首先是域名,这个需要 ICP 备案,公安备案。
如果是收费性质的,还需要 ICP 许可证。
安卓上架各大市场需要软著。
文化性质的,需要文网文,有 6 类:
1 、游戏类:游戏产品合规运营的准入许可,包含发行游戏币作为游戏里的流通货币;
2 、表演类:利用互联网进行网络在线直播表演;
3 、音乐娱乐类:网络文化经营许可证-音乐娱乐产品类经营;
4 、动漫类:利用互联网经营动漫画视听产品;
5 、展览比赛类:利用互联网进行网上文化产品的展览以及其他比赛活动;
6 、演出剧目类:利用互联网提供演出出节目的传播服务。