分布的话, 我的理解分几点, 应该属于相当肤浅的, 记录一下, 大家不要笑.
1. 数据一致, 服务器上不保存任何值, 全部上数据库, 加上内存数据库, 比如redis, 目前数据库单库性能上线为10W QPS, 容量3T 大概这样, redis大概512g的样子
2. 服务器间通信, 自己写的话大概是集中到网关或者点对点互相连接两个套路, 转发速度目前云服务器内网都能达到万兆, 甚至3万兆
3. 万一还是有逻辑要世界唯一执行, 还得有个裁决者, 如果是网关集中转发可以在这块做文章, 或者独立建立主线逻辑服务器
4. 对于客户端连接服务器这块, 如果是tcp/udp或者http协议的话, 目前有很简洁的办法就能做到负载均衡, 性能上限大概连接数是100万, 轮询能到
如果要求的各项指标都在以上范围内, 整个分布式还是比较好弄的, 如果某些组建需要集群才能满足性能, 那就某一块还需要继续细分解决方案
2018年4月27日星期五
[锤子][畅呼吸]车用空调滤芯长宽高
锤子的官网只有大概匹配车型, 对于有强迫症的我来说, 看不到具体数据实在不放心, 经过询问官网客服获得如下数据
产品型号 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, 我还是老老实实用博世的吧
产品型号 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月的时候也挂了.现在还能看看视频
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年的. 全部都部署好了. 如果你有兴趣可以来试试.
2018年4月26日星期四
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
2018年4月25日星期三
扫雷小地图优化之矩形合并
扫雷的小地图是一个动态的点阵图, 直接使用Graphics组件绘制在大屏幕绘制大概64x64空间时, 按每个数据点进行绘制时性能还算面前能够接受, 大概10几个毫秒
但是到了丧心病狂的滚动大地图时, 因为有256x256的数据, 这个数量级如果还是俺点绘制. 6万5的数据点, 每个点还都是矩形, 我的妈妈咪呀, 几十万的GL vert爽的不要不要的
所以我们要将相同的数据举行进行合并, 合并时算法还要带剪枝, 要不性能又都跑到脚本层消耗掉了.
一开始是两道循环, 用Map保存数据(是为了查找方便)
到最后是一道循环加内嵌的一道高度剪枝的循环, 数据全部用Array, 终于算是手机上效率可以接受了. 大概200毫秒左右, 90%多的性能消耗还是最后落在了Graphics的fillRect上面
用两张图简单表示一下大概意思, 黑灰的为正常显示, 彩色的是我将每个矩形都随机了RGB颜色, 希望能看明白.
但是到了丧心病狂的滚动大地图时, 因为有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都会打断渲染批次。能不用就不用,不过这个对于扫雷这种素材不多的游戏来说都还好。直接用碎图然后用自动图集就可以自动合并渲染批次。
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
订阅:
博文 (Atom)