背景

我司mysql，最早部署在物理机上，做的是1主2从，40核150G*3顶了所有业务两年。

最近云平台做了高可用的集群，新业务全部在云平台上。

随着云平台的慢慢完善，物理机部署方式慢慢显示出他的不足。

• 不再重点维护，只能保持现状
• 无法实时监控慢查询，每次都需要找dba导出
• 不支持高可用
• 后续数据库优化也只会在云平台上进行

我们近期出了多次故障，主要是以下问题导致的

• 不小心写了个大批量的循环查询
• 高频接口写了个小慢查询，没做缓存
• 低频接口写了个大慢查询，管理员多点了几次
• 更新大表字段，导致主从延迟一小时，影响业务（类似于pt-online-shema-change的机制，所以放心的在线对大表进行变更）
• 更新大表字段，主库完成，同步到从库的时候，卡在alter，导致从库数据不更新

物理机模式，监控不全，导致我们排查问题严重依赖于DBA，故着手将数据库迁移到云平台

阅读全文

背景

经营消息通常通过业务代码进行取数，并发送消息到指定的地方，不同伙伴写的逻辑分散各处，存在重复工作，逻辑耦合严重，管理困难，故设计通用的报表通知功能，对取数与通知进行解耦。

报表通知开发流程

阅读全文

雪花算法

long类型
1位无用 41位毫秒时间戳 10位实例区分 12位自增
41位毫秒可存 (Math.pow(2,41)-1)/24/3600/1000/365 = 69.73057000098301 年
10位实例区分，可表示1024个实例
12个自增位，可表示4096个Id
所以每毫秒最大能生成4194303个id

优点：

• 每个实例严格递增
• 不同实例在毫秒级的范围外递增
• 纯内存生成，性能高

缺点：

• 时间回拨，id可能会重
• js最多只支持(Math.pow(2,53)-1)的数值，再大就出问题了，故只能把他当成字符串去处理

改版雪花算法基本需求

• 还是long类型
• 取值落在 Number.MAX_SAFE_INTEGER = 2^53 -1 =9007199254740991内
• 毫秒级范围外递增

阅读全文

性能与安全的权衡

对数据库Id字段的设计，各种五花八门的都有。

• Long类型Id

数据库查询，数值比字符串性能高，正常来说会把主键设计为自增的Long类型，其他表关联也通过该字段来关联，但字段暴露到前端去，用户可以通过简单的修改id获取刷取整站的记录，安全性上存在一定的问题。

• 字符类型Id

使用字符串如uuid之类的做主键，字段安全属性，但查询效率低下。

如何做到安全与高效兼得呢。

阅读全文

吐个槽

---

作为it人员，需要经常查阅各种文档，许多官方文档写得非常好，但存在一些阅读体验问题。

一般来说，左侧是目录列表，右侧显示内容。

内容篇幅比较长的时候，需要查看下一篇，要一路拉到顶，然后睁大眼睛找到下一篇的标签，让人小小不爽了一把。

让官方去改，是不现实的，那就咱们自己来解决这个问题吧。

解决思路

---

好久之前就听说 Tampermonkey 这个浏览器插件，功能强大，但一直没去看过他到底是强大到哪，试用了下，确实。

先来看看效果

---

• 安装Tampermonkey官网：

https://www.tampermonkey.net/changelog.php?version=4.9&ext=dhdg

支持Chrome，Firefox等各种浏览器，

安装完界面如下：

阅读全文