"仁扬" 发布的文章

今天线上出现了一个很奇怪的问题,简单讲就是某个比较通用的服务反序列化 JSON 的时候,发现有些 int64 的 ID 解开之后不是预期的数字。

废话不多说!直接上代码!不看答案,你能知道输出什么吗?

package main

import (
    "encoding/json"
    "fmt"
    "log"
    "sync"
    "time"
)

type Msg struct {
    DrId int `json:"drid"`
}

type Data struct {
    Msg interface{} `json:"msg"`
}

func main() {
    msg := Msg{DrId: 21041079142844926}
    data := Data{Msg: msg}
    str2, _ := json.Marshal(data)
    // 1. {"msg":{"drid":21041079142844926}}
    fmt.Println(string(str2))
    var data2 Data
    _ = json.Unmarshal(str2, &data2)
    // fmt.Println(data2)
    str3, _ := json.Marshal(data2)
    // 2. ?
    fmt.Println(string(str3))
}

阅读全文

最近博客停更了一段时间,这是因为我把文章发布到其它平台上了,也有犹豫要不要也在我这边发表,正赶上季度末,事情也非常多,也就搁置了。

3 月份的文章是 《万字长文揭秘 37 手游的自研任务调度平台》,有兴趣的看官,可以移步链接查看。

它主要介绍了 37 手游任务调度平台的架构和实现原理,整个平台是我一个人独立开发出来的,花费了 1 个多季度的时间。

涉及的模块,有调度核心(常驻进程 + 定时任务)、Agent、后台系统三大模块,其中后台系统包含了前端(Vue.js)和后端(Go 语言)。

整个平台运行了 1 年多有余,整体上零故障,非常稳定。大家也爱不释手,每天都会使用它,确实很有成就感。

除此之外,我还在开发一些新的工具,或者说是一个工具箱。

名字暂定为『仁扬工具箱』。其中一个工具是 JSON格式化 - JSON校验 - JSON解析 - JSON视图 - 让你的JSON数据更加易读 - 仁扬工具箱

它支持在线 JSON 解析、校验、格式化、压缩、测试、编辑、树形图、可视化等功能,使用 jsoneditor 开发。

阅读全文

公司电脑存储是 128G 的,之前为了腾出空间,删除了整个 Docker 环境,它占据了我整整 60G 的磁盘空间。

后面还花了时间,把自己的开发环境,逐步迁移到公司提供的测试环境上,很多组件不需要自己搞了,很舒服。

不过,测试环境的资源经常挂掉(可能用的人多,也可能是使用的姿势不对),又得自己动手了……

简单记录一下安装的过程:

brew install java kafka

经历了漫长的等待,你会看到安装成功的提示。使用下面命令启动 Zookeeper 和 Kafka:

zookeeper-server-start /opt/homebrew/etc/kafka/zookeeper.properties
kafka-server-start /opt/homebrew/etc/kafka/server.properties

Enjoy!

最近项目需要用到中文分词,实现词云和情感分析的效果。

因为不是十分重要的业务,第一反应是想着接入外部云厂商的 API 接口:

利用大公司的机器学习模型资源,快速实现需求,我这边可以腾出时间继续做活动项目。

虽然刚过完年,但是感觉事情还是不少——很多东西都没有做好,好多代码还得优化、迁移等等。

看了腾讯云的接口,太贵了。按数据量估计一天要好多人民币!

麻了麻了……还是自己做吧哈哈!

不得不说,Go 结巴 分词非常好用,相比其他库,它速度飞快!

原版是 C++ 实现的,但我的开发语言主要是 Go,作者也给了 Go 的绑定:

https://github.com/yanyiwu/gojieba

照着官方的 Demo,很快就完成了第一版。太强大了!

不过有些句子,分词结果并不符合预期。

比如 我是奥斯卡,速来,带我飞,快点进群 这句话,

速来 被硬生生拆分成两个字,

带我飞 变成 带我

阅读全文

平时开发的过程中,需要保证消息的可靠交付。消息交付的可靠性保障,有以下三种承诺:

  • 最多一次(at most once):消息可能会丢失,但绝不会被重复发送。
  • 至少一次(at least once):消息不会丢失,但有可能被重复发送。
  • 精确一次(exactly once):消息不会丢失,也不会被重复发送。

默认是一般是 至少一次,也就是 Broker 收到并成功提交消息,并且 Producer 成功应答才会认为消息已经发送。

某些情况下,比如网络波动等,导致应答没有成功送达,会导致 Producer 重试,从而导致消息的重复发送。

阅读全文