【Pitaya-官方Demo解读笔记】7. worker demo

项目目录：examples/demo/worker

这个 demo 我是看了很久，也跟朋友、同行、群友讨论了很久，最后一致认定，worker 主要用来实现一个异步调用，并不能直接在调用侧获得回复，相当于是发送一个 job 到 worker，由 worker 来保证可靠调用，失败重试。

我们还是先把代码跑起来，待会再详细说说这个异步调用的坑。

运行

哦对了，这个 demo 需要连接 redis，demo 是直接连接到 “localhost:6379”，请在本地开启 redis，或者修改 url 到正确的地址：

// main.go:32
conf.SetDefault("pitaya.worker.redis.url", "localhost:6379")

修改 response msg

由于 demo 里的 Msg 输出都是 “OK”，不太方便看数据源头，所以我略做了一些修改：

// room.go
func (r *Room) CallLog(ctx context.Context, arg *protos.Arg) (*protos.WorkerResponse, error) {
    ...
    return &protos.WorkerResponse{Code: 200, Msg: reply.Msg}, nil // 改成 WorkerResponse 的原因见后文的填坑部分
}

// metagame.go
func (m *Metagame) LogRemote(ctx context.Context, arg *protos.Arg) (*protos.WorkerResponse, error) {
	logger.Log.Infof("argument %+v\n", arg)
	return &protos.WorkerResponse{Code: 200, Msg: "msg from metagame"}, nil
}

// worker.go
func (r *RPCJob) RPC(ctx context.Context, serverID, routeStr string, reply, arg proto.Message) error {
	err := r.app.RPCTo(ctx, serverID, routeStr, reply, arg)
	logrus.Infof("rpc to %s, route: %s, reply: %+v, arg: %+v", serverID, routeStr, reply, arg)
	return err
}

好了，服务器，启动~！

1. 开启 metagame 服务器

go run main.go

2. 开启 room 服务器

go run main.go -port=3251 -type=room

3. 开启 worker 服务器

go run main.go -port=3252 -type=worker

如果你能成功开启、且连接上 redis，恭喜，你可以跳过下面的填坑部分~

解决服务器启动失败的错误（填坑）

redis 是带密码的

我本地之前部署过 redis 是带密码的，懒得改了，所以开起来的时候会报错：

time="2023-12-07T11:30:39+08:00" level=error msg="failed to fetch message NOAUTH Authentication required." source=go-workers

worker 从 redis 拉数据的时候报权限错误了，我们需要在代码里配置一下访问密码。
这个 demo 中使用 viper 来配置，在配置字典里只将 url 和 pool 做了映射，没有映射 password 到实际的 config里，那我们加一下：

// viper_config.go:139 加一行映射
pitaya.worker.redis.password": workerConfig.Redis.Password,

main 里配置一下：

// main.go:34
conf.SetDefault("pitaya.worker.redis.password", "your_password")

protos.Response 注册冲突

我本地的代码已经改掉了，没有保留之前的报错提示，这里就不给出原提示了（就是懒得 revert 了哈~）
这个错误是因为 worker demo 的 pb 生成文件 response.pb.go 里有一个包 init 函数，会注册 type “protos.Response”，这个名字与 pitaya 框架里的 response.pb.go init 中的冲突了，两个同名了。
所以把 demo 中的文件改名为 worker_response.pb，再重新用 protoc 生成一下就好了（具体如何生成，网上很多文章，此处不扩展了）。

invalid memory address or nil pointer

worker 服务有概率会报这个错误，这个我没有细看，感觉 worker 这边的问题挺多的，pitaya 的 worker 也是在别人开源的一个 worker 基础上做了封装，不多余花时间去 debug 了，如果报这个错误的话，多尝试几次就可以正常开启。如果你的项目需要用到这个功能，还得注意这个坑，自己解决一下吧~（我是觉得这东西挺鸡肋的哈哈）。

测试 demo

按照以上一波操作，服务器总算是开启来了（不知道你们还会不会遇到别的坑……），让我们开启 pitaya-cli 测试一下：

pitaya-cli
Pitaya REPL Client
>>> connect 127.0.0.1:3251
Using json client
connected!
>>> request room.room.calllog {"msg":"hello"}
>>> sv->{"code":200}

依次看看几个服务器的日志（把 time 部分都截掉了，不然太长了）：

1. room

level=debug msg="SID=4, Data={\"msg\":\"hello\"}" requestId=L0eYEIdBTVSZuPQNk1uHFD route=room.room.calllog source=pitaya userId=
level=info msg="enqueue rpc job: %!d(string=3191b5e2de7968051b21bac7)" source=pitaya
level=debug msg="Type=Response, ID=4, UID=, MID=1, Data=12bytes" source=pitaya

2. metagame

level=info msg="argument msg:\"hello\" \n" source=pitaya

3. worker

level=debug msg="executing rpc job" source=pitaya
level=debug msg="getting route arg and reply" source=pitaya
level=debug msg="unmarshalling rpc info" source=pitaya
level=debug msg="choosing server to make rpc" source=pitaya
level=debug msg="executing rpc func to metagame.metagame.logremote" source=pitaya
level=debug msg="[rpc_client] sending remote nats request for route metagame.metagame.logremote with timeout of 5s" source=pitaya
level=info msg="rpc to , route: metagame.metagame.logremote, reply: code:200  msg:\"msg from metagame\", arg: msg:\"hello\" "
level=debug msg="finished executing rpc job" source=pitaya

根据日志我们大概能看出几点：

1. cli 端只输出了 code 而没有 msg，所以这个 ReliableRPC 虽然传递了 reply，但并没有赋值，这里是拿不到回复的。如果你断点看的话，会发现 ReliableRPC 其实是一个异步调用，直接就返回了；
2. metagame 输出了 hello，与预期一致，这个没啥好解释的；
3. worker 那一行 info 日志注意看，在 worker 既能拿到 cli 端的请求参数 hello，也能拿到 metagame 返回的消息数据 msg from metagame。

接下来，我们从代码层面追踪一下整个调用链。

代码分析

先看看调用链的头部，room CallLog，我们刚才使用 pitaya-cli 发送的 request 就是 room.room.calllog。

起点：room.CallLog

// CallLog makes ReliableRPC to metagame LogRemote
func (r *Room) CallLog(ctx context.Context, arg *protos.Arg) (*protos.WorkerResponse, error) {
	route := "metagame.metagame.logremote"
	reply := &protos.WorkerResponse{}
	jid, err := r.app.ReliableRPC(route, nil, reply, arg)
	if err != nil {
		logger.Log.Infof("failed to enqueue rpc: %q", err)
		return nil, err
	}

	logger.Log.Infof("enqueue rpc job: %d", jid)

	return &protos.WorkerResponse{Code: 200, Msg: reply.Msg}, nil
}

很明显，重点是这行代码 r.app.ReliableRPC(router, nil, reply, arg)，根据命名，猜测是发起了一个远程调用，调用的目的地为 metagame.metagame.logremote，请求消息为 arg，回复数据填充到 reply。我是这么猜的，可惜，就猜对了一部分……前面也提到过，这里的 reply 其实并无回复数据填充，ReliableRPC 只是一个异步调用。
老规矩，跟进源码看一下。

room ReliableRPC

// rpc.go
// ReliableRPC enqueues RPC to worker so it's executed asynchronously
// Default enqueue options are used
func (app *App) ReliableRPC(routeStr string, metadata map[string]interface{}, reply, arg proto.Message) (jid string, err error) {
	return app.worker.EnqueueRPC(routeStr, metadata, reply, arg)

看注释也知道，这是一个异步调用，入队一个请求到 worker，让他去异步执行，与其说这是一个 rpc，我更愿意理解成 job 或者 task，扔过去就不用管了，由 worker 来保证可靠执行。
app.worker 是在框架层 NewBuilder 里默认创建的，也就是说，即使你压根不想用这个什么 worker，它依然会在底层给你创建这么个东西，但不生效，如果想要用上 worker 的功能，还需要手动调用 app.StartWorker()，里面的逻辑不深究，继续看回我们的 demo。
EnqueueRPC 做了什么呢？

// worker/worker.go
func (w *Worker) EnqueueRPC(routeStr string, metadata map[string]interface{}, reply, arg proto.Message) (jid string, err error) {
	opts := w.enqueueOptions(w.opts)
	return workers.EnqueueWithOptions(rpcQueue, class, &rpcInfo{
		Route:    routeStr,
		Metadata: metadata,
		Arg:      arg,
		Reply:    reply,
	}, opts)
}

// go-workers包 -> enqueue.go
func EnqueueWithOptions(queue, class string, args interface{}, opts EnqueueOptions) (string, error) {
	now := nowToSecondsWithNanoPrecision()
	data := EnqueueData{
		Queue:          queue,
		Class:          class,
		Args:           args,
		Jid:            generateJid(),
		EnqueuedAt:     now,
		EnqueueOptions: opts,
	}

	bytes, err := json.Marshal(data)
	if err != nil {
		return "", err
	}

	if now < opts.At {
		err := enqueueAt(data.At, bytes)
		return data.Jid, err
	}

	var conn redis.Conn
	if len(opts.ConnectionOptions) == 0 {
		conn = Config.Pool.Get()
	} else {
		conn = GetConnectionPool(opts.ConnectionOptions).Get()
	}
	defer conn.Close()

	_, err = conn.Do("sadd", Config.Namespace+"queues", queue)
	if err != nil {
		return "", err
	}
	queue = Config.Namespace + "queue:" + queue
	_, err = conn.Do("lpush", queue, bytes)
	if err != nil {
		return "", err
	}

	return data.Jid, nil
}

代码比较简单，只看核心逻辑，就是把请求数据打包、序列化后写入到 redis（具体这两个 redis key 是怎么拼的，内容是什么，这些细节就不用太在意）。
另外，它会返回一个随机生成的 jid，理论上可以理解为一段时间内的唯一 id，标识这一次的 rpc。所以看到这里的时候，我以为还会有什么 api 可以通过这个 jid 来获取这次请求的返回消息，然而并没有……其实 pitaya 用的第三方开源库 go-workers 也提供了对 jid 的获取：

// go-workers库 -> msg.go
func (m *Msg) Jid() string {
	return m.Get("jid").MustString()
}

但是 pitaya 并没有使用过，猜测 pitaya 并没有完全用上 go-workers 库，做了部分简化，或者有一些功能是留给开发者自己在业务层去实现的，pitaya 在设计上只把 worker 当作一个异步可靠的 job scheduler 来用。

看过了一个 job 的投递，我们再看看逻辑链条的第二部，这个 job 是如何被获取并执行的呢，让我们进入 worker 流程~

worker Configure

// Configure starts workers and register rpc job
func (w *Worker) Configure(app pitaya.Pitaya) {
	app.StartWorker()
	app.RegisterRPCJob(&RPCJob{app: app})
}

前面说到，worker 功能必须要调用 StartWorker 才可以使用，这里主要是开启几个 goroutine，从 redis 中获取待处理的 job 队列（即前面通过EnqueueWithOptions 写进去的）并执行。这部分已经是第三方库 go-workers 的内容了，不去管这些细节了（没错，内容太多了，就是我懒得看了……）。

还是回到 pitaya 的代码上来，RegisterRPCJob 用来将 job 的处理方式注册到程序里：

// RegisterRPCJob registers a RPC job
func (w *Worker) RegisterRPCJob(rpcJob RPCJob) error {
	if w.registered {
		return constants.ErrRPCJobAlreadyRegistered
	}

	job := w.parsedRPCJob(rpcJob)
	workers.Process(rpcQueue, job, w.concurrency)
	w.registered = true
	return nil
}

那我们看看如何定义一个 RPCJob。

worker RPCJob

// rpc_job.go
// RPCJob has infos to execute a rpc on worker
type RPCJob interface {
	// ServerDiscovery returns a serverID based on the route
	// and any metadata that is necessary to decide
	ServerDiscovery(route string, rpcMetadata map[string]interface{}) (serverID string, err error)

	// RPC executes the RPC
	// It is expected that if serverID is "" the RPC
	// happens to any destiny server
	RPC(ctx context.Context, serverID, routeStr string, reply, arg proto.Message) error

	// GetArgReply returns the arg and reply of the
	// method
	GetArgReply(route string) (arg, reply proto.Message, err error)
}

ServerDiscovery 用来实现路由策略，与我们之前在 cluster demo 里说的 AddRouter 功能类似。
RPC 在本例中，就是调用了 pitaya 的 RPC：

// RPC calls pitaya's rpc
func (r *RPCJob) RPC(ctx context.Context,serverID, routeStr string, reply, arg proto.Message) error {
	err := r.app.RPCTo(ctx, serverID, routeStr, reply, arg)
	logrus.Infof("rpc to %s, route: %s, reply: %+v, arg: %+v", serverID, routeStr, reply, arg)
	return err
}

串下来的逻辑流是这样的：

1. room 写 job 到 redis
2. worker 从 redis 拉去到待执行的 job
3. worker 在 RPC 中执行 job

GetArgReply 就是返回空的请求和回复结构，应该是帮助解析从 redis 中取出的数据，否则在 worker 这里无法确定如何反序列化。所以 GetArgReply 是为了提供反序列化数据的模板。

回到 pitaya 底层，看一下这三个方法是如何依次被调用的。
前面我们提到了 RegisterRPCJob，其中调用了 parsedRPCJob，就是这个方法实现了 worker 解析数据、执行的流程串联：

// worker/worker.go
func (w *Worker) parsedRPCJob(rpcJob RPCJob) func(*workers.Msg) {
	return func(jobArg *workers.Msg) {
		logger.Log.Debug("executing rpc job")
		bts, rpcRoute, err := w.unmarshalRouteMetadata(jobArg)
		if err != nil {
			logger.Log.Errorf("failed to get job arg: %q", err)
			panic(err)
		}

		logger.Log.Debug("getting route arg and reply")
		arg, reply, err := rpcJob.GetArgReply(rpcRoute.Route)
		if err != nil {
			logger.Log.Errorf("failed to get methods arg and reply: %q", err)
			panic(err)
		}
		rpcInfo := &rpcInfo{
			Arg:   arg,
			Reply: reply,
		}

		logger.Log.Debug("unmarshalling rpc info")
		err = json.Unmarshal(bts, rpcInfo)
		if err != nil {
			logger.Log.Errorf("failed to unmarshal rpc info: %q", err)
			panic(err)
		}

		logger.Log.Debug("choosing server to make rpc")
		serverID, err := rpcJob.ServerDiscovery(rpcInfo.Route, rpcInfo.Metadata)
		if err != nil {
			logger.Log.Errorf("failed get server: %q", err)
			panic(err)
		}

		ctx := context.Background()

		logger.Log.Debugf("executing rpc func to %s", rpcInfo.Route)
		err = rpcJob.RPC(ctx, serverID, rpcInfo.Route, reply, arg)
		if err != nil {
			logger.Log.Errorf("failed make rpc: %q", err)
			panic(err)
		}

		logger.Log.Debug("finished executing rpc job")
	}
}

前文我们提到了，worker 的 RPC 是可以获取到 metagame 返回的消息，就在 reply 里，但是他并没有做处理，也就是说并没有写入 redis 缓存，或者返回给调用方 room。这里就是佐证，rpcJob.RPC(ctx, serverID, rpcInfo.Route, reply, arg) 调用后，对于 reply 回复数据没有作进一步处理。
这里的代码是当然是可以改造的，再来一个 RPC 将 reply 返回给调用端，或者写入 redis 让调用端拿着 jid 去获取回复。我们这里就不讨论了，就像前文提到的，pitaya 的本意可能只是把 worker 当做一个 job scheduler 来使用，而并不是我们平时所理解的 RPC。

由于这个 demo 写得比较糙，不详细（pitaya 的所有 demo 都这样……），还涉及到了第三方库及其封装，背后的代码还挺多的，时间有限，能力有限，我大概也就断断续续看了一天写了一天，难免有纰漏，如果你发现疏漏、错误，或者有不同理解，欢迎留言~

至此，pitaya 框架的几个 demo 都大概过完了，不过我们还有很多底层代码并没有涉及到，不急，接下来，我们先试着实现自己的简单服务器，下一篇，进入实战环节，共勉！