什么问题

解决规模效率的问题, 基本思路是如果数量越多, 就让他的成本更低

举个例子:

我们店里有三种一次性商品: 纸杯, 手套, 口罩

商品的货架位置分别在 1 米(纸杯), 3 米(手套), 5 米(口罩)

而根据我们出货数量的统计发现

口罩每天能卖 100 个, 手套 20 个, 纸杯 10 个

这样我们算一下每天总共需要走多少米

1
2
3

100个口罩 * 5米(口罩货架的位置) + 20个手套 * 3米(手套货架的位置) + 10个纸杯 * 1米(纸杯货架的位置)

100 * 5 + 20 * 3 + 10 *1 = 570米

总觉得哪里不太对劲啊

日志满了

收到告警 clickhouse-zookeeper 的告警

zookeeper 其实是有参数可以实现自动清理以前的数据

1
2
3
4

# 间隔多久进行一次清理
autopurge.purgeInterval: int, default=0
# 保留多少个数据, 这里包括日志和快照的数据
autopurge.snapretaincount: int, default=3

Blog 的问题

之前使用 hexo+github 部署 BLOG 环境

使用 vscode+markdown 来写 Blog

但是体验很不好, 主要有两个原因

1. 有一些内容记录在云笔记中, 总是需要而外的花时间转换成 Blog

2. Blog 中涉及到图片的内容处理起来很麻烦

因为这两个原因, 导致 Blog 长时间没更新

于是想找找看有没其他更好的办法

是什么

从使用角度来看是一个分析型数据库

从实现角度来看是一个列式数据库系统

分析型数据库和事务型数据库

字面意思是为了分析数据的数据库, 特点是需要存储的数据非常多

但是对数据的一致性没有要求, 因为分析数据后看的是趋势, 小部分数据的错误不影响总体的趋势

相对应的是事务型数据库

事务是什么

简单来说, 是不可分离的多个动作

讲到事务就不得不讲讲事务四个特性

原子性, 要么都成功, 要么都失败
一致性, 同一个事务中, 多次查询的数据要一致
隔离性, 每个事务要尽可能的不影响其他事务
持久性, 写入后不能丢失数据

事务性数据库对一致性要求很高

分析型数据库对海量数据要求很高

分析型的数据库一般没有一致性, 隔离性, 原子性, 但是肯定会有持久性

什么是列式数据库

比如有三条记录

1
2
3

1,clickhouse,database
2,mysql,database
3,nginx,web

如果我们按照每行进行存储, 那就是行式数据库

比如这样存储:

1

1,clickhouse,database|2,mysql,database|3,nginx,web

而我们在分析数据的时候经常会选取几列的数据进行统计分析

如果是行式存储的话, 会将整条的数据也一并读取出来(核心思想是减少

1

1,2,3|clickhouse,mysql,nginx|database,database,web

而如果是列式数据库, 则只会读取相关列的数据

通常随着数据的增大, 磁盘的 IO 会首先出现瓶颈.

采用列式数据库能够的大量减少读取的数据

并且在因为每列的数据类型都是相同的, 所以每列都能压缩数据, 减少存储大小

因为总数据量的减少, 所以在磁盘 IO 又进一步的降低了.

但是涉及到压缩和解压, 导致相比于其他数据库会使用更多的 CPU 资源

所以, clickhouse大部分情况下都是CPU先跑满, 而磁盘IO方面不会成为瓶颈

分布式数据库?

这样说可能不对劲, 因为 clickhouse 的分布式是体现在 table 层的.

打个比方, 我们有 10 万条数据, 两个节点, 不考虑双副本的情况下(高可用)

将 5 万条数据存入节点 1, 另 5 万条数据存入节点 2

这个存储数据的东西叫做本地表, 是保存了实实在在的数据

另外通过创建分布式表将本地表关联起来, 从而实现分片的效果

我们查询数据的时候直接实用分布式表名, 分布式表会自动帮我们去每个本地表上查询数据

然后在进行聚合汇总

那我们写数据的时候也写入分布式表吗?

分片和负载均衡

clickhouse 分片和其他分布式集群有点不太一样.

我们确实可以将数据写入分布式表

但是规模(日千亿级别, 百 M/s)上来了后不太推荐这种做法

主要是数据性能和数据一致性的问题.

本机的分布式表收到请求后会将数据存放在临时文件

然后再尝试将数据写入相应的分片, 造成了写放大

推荐写入数据的方式是, 通过负载均衡将数据写入不同的分片

从逻辑上来说, 每个分片是相互独立的数据

具体的数据分布情况要看负载均衡的调度策略, 以及每次写入 batch 的大小

这个需要在业务使用中多加注意

总结

非常适合用来做用户行为分析

大部分应用的瓶颈都在 IO 上, clickhouse 的架构设计避开了这点

最大限度的利用了多核的优势, 比如从磁盘读取数据后的并行解压, 以及数据分片的使用

但是在查询使用过程中需要做一些兼容.

一个大胆的想法

既然 clickhouse 能够存储大量的数据并且把数据压缩起来.

是不是可以将游戏通信中的数据存入 clickhouse 中.

这样可以分析游戏中的热点请求以及, 帮助游戏排查业务Bug

故障表现

在启动 job 时随机出现 checkpoint 无法完成的情况

但只要 job 能够正常跑起来就一直都没有问题

没有任何的错误日志

需求

H5 游戏研发公司
需要将 H5 项目的 URL 给合作方进行测试,

问题

避免游戏地址被外部传播

方案

使用 openrestry 作为反向代理
在后台通过对项目地址, 过期时间等信息进行对称加密.
生成一个 url 链接，然后发送给合作方

合作方使用浏览器打开 url 时， openresty 会收到 http 请求
并对 url 参数中的加密信息进行解密, 获取项目地址，过期时间等相关的信息

如果当前时间大于过期时间则返回相应过期提示
如果当前时间小于过期时间则通过 proxy_pass 进行代理请求

大致的情况就是这样了

client—-gateway url—->openresty—-project url—->project
client<—-response data—-openresty<—-response data—-project

问题背景

之前有提到过, 我们将游戏本地的数据库集中起来进行存储.

在整体方面是有了大幅度的提升, 包括迁移, 监控, 高可用, 以及备份.

尤其时在迁移方面, 我们将单个服10-30分钟的迁移时间压缩到了1-3分钟(不用迁移数据库).

然而, 之前的的数据库瓶颈分布在 5,6 台主机上, 现在却集中在一台 4 核 16G 的主机上.

这明显会产生其他的问题, 比如我们处理过的 CPU 高突发以及 binlog 数据量过大.

以及目前碰到了二个新问题

前戏

其实一开始, 写这东西我其实是拒绝的.

因为感觉没有多少技术含量, 没法体现出我牛逼的地方.

后来想了想, 很多思想和方法还是挺不错, 可以深挖和借鉴.

所以就记录下来, 方便以后回顾.

以上.

问题背景

1. 本地数据库使用 5.6 的 MyISAM 引擎.
2. 业务没有使用事务, 存储过程, join, 之类的常规关系数据查询
3. 直接粗暴简单的将用户数据序列化 json 后存在多个 BLOBTEXT 字段里.
4. 每个小时的整点进行锁表备份, 导致 CPU 的间隔性的突发.

我们需要做的是在效率, 安全, 成本之间做平衡

迁移

在游戏服导量过后的一段时间.
需要定期的对游戏服进行迁移.
以提高资源使用率从而降低成本.

数据库在本地时, 迁移需要对数据库进行导入导出操作
既不安全, 效率也低.

备份

本地的数据库使用是的每小时备份.
在备份时会占用本地主机的资源, 影响用户体验.

性能

本地数据库都是机械磁盘
同时大批量的停止和启动服务时会有大量的数据库操作
这些操作大都是磁盘的瓶颈, 拉长了维护的时间

回档

当研发需要查询某个时间的数据时只能按每小时回档

崩溃

没有对数据库做高可用, 当数据库崩溃时影响业务的数据安全

背景问题

我们的运维平台是基于 SaltStack 封装的任务系统.
在任务系统上将需要执行多个操作转为不同的 state
SaltStack 负责进行调度执行, Minion 执行完了之后, 会将数据结果返回给 master
而 master 则将结果保存在 mongodb 里面, 看图

问题背景

我们是一家 H5 的研发公司.
运营突然报业务故障, 玩家登录不了(监控没做好, 真的是没人啊..)
点击进入游戏时转圈圈, 提示连接超时(找不到图了, 发挥一下想象吧)

排查思路

经过我们的沟通, 得出信息

1. 只有 IOS 的用户有问题
2. 只有某个特殊渠道有问题
3. 同样的手机访问其他游戏没问题
4. 同样的账号换手机登录没问题
5. 没有更新版本和变动

这样来看, 肯定是渠道方更新了什么导致的故障

客户端只有连接超时的信息.
服务端上只有一行http hand failed, 没有任何其他信息