最近接了不少支付相关的sdk，自己看下来发现这个业务其实蛮固定的套路。这里做下总结

最近再调整游戏服务器的架构，有了些感悟，趁着热乎先记录下来。

为啥是一首歌，因为新的需求是极端情况可以忍受玩家回档5分钟。哪些极端情况呢？redis完全不能用了，只能走mysql来落地。来保护玩家数据。

不过有个明显的问题是：mysql到底能不能抗此大责任？

个人觉得要防住外挂，最好的方案就是一切走服务器来验证。尤其是一些关键性的数据，比如血条，装备和位置。

去年年底封测的第一个晚上，晚高峰时候，本来一切平和。但是在毫无征兆的情况下，突然线上redis断了。检查了机房连接没有问题，并且线上10多个实例，只有一台机器的redis断掉了。十分诡异！排查了一个小时没有任何结果，此次问题造成了大概800人回档。对于当时近万人的同时在线，还算损失比较小。

最近读到官网的一篇文章 https://redis.io/topics/protocol, 主要是描述了一下redis在通讯协议。忽然觉得豁然开朗：redis作为作为一个内存数据库，其实其本质也是一个服务器而已。监听在6379（默认）接口，然后定义了一套自己的命令方便调用者使用。

其实市面上的主流第三方客户端都会遵守这套协议。只不过实现的语言不一样而已。这里试着分析这套协议，并且写一个简单的“redis客户端”。

今天下午，突然线上出现大量高级掉落重复出现。
正常的概率是1%，结果部分玩家出现了很多。导致了群里炸了锅。于是开始分析掉落部分代码：

希望通过这篇文章能解释清楚elk中的时区问题

今天调查了一个奇怪的问题，在其他日志都是看起来的情况下，突然发现某个日志在5号凌晨开始后没有被收录了。

最近压测发现日志在抽奖接口会放大百倍，直接把10万长度的日志队列挤爆！

最近压测登陆接口，发现处理超过1k的byte对象（我们初始化就有3k,跑起来后可以达到40k）时候，整体的tqs下降得十分厉害。从一般几千得并发掉落倒了不到一千，还有不少得错误。

最近我们游戏调整了服务器架构，所以涉及到一些文件系统的改动。类似于文件重命名之类。按照之前的理解这种操作在停服时候做，通过脚本应该是比较安全快捷的。不过正式由于这个操作，让我花了一个通宵才查明一个filebeat的问题。

专门用来总结一些经验和想法，不一定正确

这一个月经过努力好不容易把我们的游戏送上了steam。中间踩了不少坑，无数次的加班才换来的结果。当然现在回国头去看一切还是挺值的。游戏在没有任何推广情况下，口碑和数据都保持得不错。每天在留言板和q群里面看玩家和我们的互动也慢慢成为我得日常部分。今天好不容易闲下来了一点，对过去一段时间做个回顾看看

docker 启动后有一个需求便是如何处理以及收集它产生的日志。
这里的日志可以分为3类： docker的引擎日志， docker 容器日志， docker 应用日志

对于自定地图来说，接入支付应该是比不可少的步骤。这里主要以支付宝为例子来说明下大概流程

为了后面方便快速开发自定义英雄和技能，决定开坑先做个KV编辑器。有依赖一个第三方的库来实例化KV。

通常测试时候是需要加入一些机器人的。那么在workshop中如何加入呢？

背景

最近研究dota2rpg时候发现一个问题：游戏流程如果使用官方的做法会比较死板。比如你必须选完队伍，然后再去选择英雄，然后再开始游戏。当然这个不是说它不好，但对于一款高度定制化的地图编辑器来说，这着实会束缚开发者的能力。很多优秀的rpg地图都可以定制整个游戏前的流程。

目的

主要测试dotnetty在大包体，或者粘包情况下的表现

目的

通过测试数值来比较两个库的优劣

背景

我们已经基于标准shell建立了一整套服务器环境搭建体系，在平常运维中，其实只要记住那一步执行哪个shell脚本就好了。但是执行了一段时间后，还是觉得不够灵活。想象如下场景：有一天你刚回收完一套环境，这个时候来了个需求需要尽快搭建一套独立环境之类。这个时候需要重新执行一次所有的脚本，时间比较慢，并且数据可靠性也无法保证。这个时候我想到了docker，虽然我们有在测试环境部分使用它的功能，但并没有真正拿他做到开箱即用

背景

最近关注了比较多的独立游戏，比如《eastward》，《the last night》和《迷雾侦探》的美术风格一下子吸引了我。经过一些资料的翻阅，发现实现它的美术效果其中很重要的一点就是 法线贴图。