对于分布式理解

分布的话, 我的理解分几点, 应该属于相当肤浅的, 记录一下, 大家不要笑.
1. 数据一致, 服务器上不保存任何值, 全部上数据库, 加上内存数据库, 比如redis, 目前数据库单库性能上线为10W QPS, 容量3T 大概这样, redis大概512g的样子
2. 服务器间通信, 自己写的话大概是集中到网关或者点对点互相连接两个套路, 转发速度目前云服务器内网都能达到万兆, 甚至3万兆
3. 万一还是有逻辑要世界唯一执行, 还得有个裁决者, 如果是网关集中转发可以在这块做文章, 或者独立建立主线逻辑服务器
4. 对于客户端连接服务器这块, 如果是tcp/udp或者http协议的话, 目前有很简洁的办法就能做到负载均衡, 性能上限大概连接数是100万, 轮询能到
如果要求的各项指标都在以上范围内, 整个分布式还是比较好弄的, 如果某些组建需要集群才能满足性能, 那就某一块还需要继续细分解决方案

[锤子][畅呼吸]车用空调滤芯长宽高

锤子的官网只有大概匹配车型, 对于有强迫症的我来说, 看不到具体数据实在不放心, 经过询问官网客服获得如下数据
产品型号 JAF5200055 产品尺寸 205*269*33mm
产品型号 JAF4200052 产品尺寸 225*234*30mm
产品型号 JAF4200048 产品尺寸 238*204*33.5mm
产品型号 JAF4200125 产品尺寸 529*237*29mm
产品型号 JAF5200067 产品尺寸 280*240*34mm
产品型号 JAF4200041 产品尺寸 193*214*30mm
产品型号 JAF6210066 产品尺寸 264*284*44mm
好吧, 我的是246x188x34, 我还是老老实实用博世的吧

无尽扫雷-从开发到挂起

0. 起止时间:

2017年11月11日 立项
2018年4月27日 挂起
游戏只上架成功了Google Play地址  国内下载地址
没有装google框架的话应该会显示游客登录, 也能试试.

1. 起因:

那是双十一很偶然的一天, 在youtube上看到一个视频. 说的是一款网页版本的扫雷游戏. 竟然是没有边界的, 可以让全球人一起玩的那种. http://mienfield.com/ ps: 这个网站差不多1月的时候也挂了.
现在还能看看视频

当时觉得这个创意好酷, 再到google play和app store上搜索了一下. 竟然没有任何一款无尽版本. ok! 立项!

2. 开发过程:

2.1 确定实现方式

选择go和cocos creator作为双端实现方案, 并初步学习差不多用了1个月.(2017年11月-12月).
一开始打算用熟悉的C++来做双端, 毕竟和之前挂机游戏一脉相承. 不过考虑想顺便学点新东西, 服务端采用了Golang实现的leaf框架制作, 客户端采用Creator的TS来写.

2.2 密集开发

密集开发游戏功能(2017年12月-2018年2月春节前夕)
实际做起来还是发现不少挺费事的地方, 但是担心如果大规模数据进来, 游戏服要能动态扩展. 就写成了无状态可分布式游戏服+redis缓存+mysql最终持久化.
而客户端也经历了好多次性能优化, 才打到了满意的效果. 毕竟同时加载近2000个节点. 还需要绘制小地图.
最终, 客户端代码+服务端代码一共差不多2W行的样子. 边陪闺女边做差不多3个月.

2.3 提交

对接与提审(2018年3月-4月底)
对接的时候Google的麻烦多, 调试起来必须非大陆账号才能正常内购, 最后还是买的礼品卡解决的真实环境测试.
提审的时候就是苹果的蛋疼了. 尝试了大半个月都被打回了. 最后两次一次判定
Guideline 4.3 - Design 说是spam经过解释后判定Guideline 4.1 - Design - Copycats
只能暂时搁置了.

3. 挂起

终归还是上线成功了google play, 还是凭借前些时阿里云的便宜服务器, 购买了3年的. 全部都部署好了. 如果你有兴趣可以来试试.

SS+BBR加速

0. 安装前提

KVM的VPS, CentOS 7, Vultr上试过6个机房, 都没问题.

1. 安装ShadowSocks

wget --no-check-certificate -O shadowsocks-all.sh https://raw.githubusercontent.com/baihowff/shadowsocks_install/master/shadowsocks-all.sh
chmod +x shadowsocks-all.sh
./shadowsocks-all.sh 2>&1 | tee shadowsocks-all.log

2. 安装BBR

wget --no-check-certificate https://github.com/baihowff/across/raw/master/bbr.sh && chmod +x bbr.sh && ./bbr.sh

3. 检查BBR

sysctl net.ipv4.tcp_available_congestion_control
sysctl -n net.ipv4.tcp_congestion_control
lsmod | grep bbr

每个返回都有bbr就说明成功了😊

扫雷小地图优化之矩形合并

扫雷的小地图是一个动态的点阵图, 直接使用Graphics组件绘制在大屏幕绘制大概64x64空间时, 按每个数据点进行绘制时性能还算面前能够接受, 大概10几个毫秒
但是到了丧心病狂的滚动大地图时, 因为有256x256的数据, 这个数量级如果还是俺点绘制. 6万5的数据点, 每个点还都是矩形, 我的妈妈咪呀, 几十万的GL vert爽的不要不要的
所以我们要将相同的数据举行进行合并, 合并时算法还要带剪枝, 要不性能又都跑到脚本层消耗掉了.
一开始是两道循环, 用Map保存数据(是为了查找方便)
到最后是一道循环加内嵌的一道高度剪枝的循环, 数据全部用Array, 终于算是手机上效率可以接受了. 大概200毫秒左右, 90%多的性能消耗还是最后落在了Graphics的fillRect上面
用两张图简单表示一下大概意思, 黑灰的为正常显示, 彩色的是我将每个矩形都随机了RGB颜色, 希望能看明白.

CocosCreator多节点优化杂谈

无尽扫雷大多数功能都已做完，进行性能调优。本以为只要用了缓存池就不会存在过多问题，哪知道不卡只是桌面浏览器WebGL里的事情。
直接说结论，调试的血泪史就不扯淡了。

• 预制首先还是要全部由NodePool进行缓存，缓存在加载场景时逐步加载。
• 扫雷节点，替换资源时，直接用loadRes效率还是不足，把通用的spriteFrame缓存，改扫雷资源的时候直接等于上去会快很多
• 尽量避免大规模js与原生层通信频率，1200多个节点一起setPosition在move事件不可取。要直接移动他们的父节点
• 由于扫雷一共管理1200多个扫雷节点，如果只用NodePool还是有轻微卡顿，修改节点的parent还是需要一定时间的。如果能把要删除的节点直接改个资源换个坐标，效率比NodePool高。
• label的非fnt字体，描边，节点的mask都会打断渲染批次。能不用就不用，不过这个对于扫雷这种素材不多的游戏来说都还好。直接用碎图然后用自动图集就可以自动合并渲染批次。

好了，差不多就这么些。通过这些细节处理，基本达到了流畅扫雷目的。至少在骁龙626上是这样。

vscode去掉go语言绿色波浪

两个办法, 一个是还是用golint做提示, 屏蔽W,C

"go.lintTool": "golint",

"go.lintFlags" : [

"--disable=W,C"

],

另外一个是用megacheck做lint工具

"go.lintTool": "megacheck",

不过megacheck需要自己去go get一下, 不过话说这东西比golint卡一些

go get honnef.co/go/tools/cmd/megacheck

Hello World, again!

时隔数年, BaihowFF.com又重新回来了.
虽然blog越来越边缘化了, 还是以此blog记录一些所思所想