b站泄露的openbilibili源码，网上到处都是，比如 https://gitee.com/guiyunweb/openbilibili

关于在Goland IDE里读这个openbilibili项目方便自动跳转到定义处以调用处，直接把这个项目放到go path下，注意要把名字openbilibili改成go-common 比如我gopath是/home/zjsxwc/go 那么项目代码目录就是  /home/zjsxwc/go/src/go-common/  然后goland打开这个目录项目就行。

每个功能模块都会被编译成一个可执行文件，见app/main/service/<功能模块名>/cmd/main.go

这个可执行文件，会对外提供三种调用， 1. http接口 2. 内部基于tcp直接调用的b站自己写的gorpc  3. 各个语言都通用的grpc

实际业务实现在 app/main/service/<功能模块名>/service/<各个文件>.go 中，

一般都会至少提供一个叫/ping的http接口用于监控和一个 /register 的http接口提供用于服务注册发现的数据。

每个队列的job也被编译成了可执行文件，见 app/job/main/<功能模块名>/cmd/main.go 以及 app/job/main/<功能模块名>/service/service.go中，一般job的线程函数在consumeproc，

cmd/main.go还会对外提供http接口控制，一般都会至少提供一个叫/ping的http接口用于监控。

有些接口会有缓存与真实实现多个出现，真实实现以Raw开头，比如 RawUserCoin() 就是通过sql查数据库的，而不以Raw开头的UserCoin()是通过缓存或者rpc获取数据

涉及数据库事务包裹的sql方法会以Tx开头，比如TxUpdateCoins

b站代码对于高频率接口请求，会使用的队列配合cache缓存实现：

比如被点赞加币，就会

同时 -------->  不阻塞发起队列异步job ->    更新cache中的用户币数目

+++++++++++++++|

+++++++++++++++|

同时 -------->     job中更新数据库的用户真实币数目

一般job下的DAO（在app/job/main/<功能模块名>/dao/<各个文件>.go）都是直接数据库操作，而service下的DAO（在 app/main/service/<功能模块名>/dao/<各个文件>.go）则会涉及rpc、缓存、队列、数据库等多种数据来源

代码中的毒屎：

队列的databus中library/queue/databus/databus.go:59  redis的命令被故意写错，把PUBLISH写错了set，把SUBSCRIBE写错了mget

_cmdPub     = "SET"
_cmdSub     = "MGET"

redis.ByteSlices(c.Do(_cmdSub, "")) 这条被订阅subscribe的主题被故意写成空字符串。