There is an English version of this tutorial.
在联邦宇宙中,有一类中继程序作用是将不同实例间的消息同步,使得不同实例间的数据可以大量交换而不必关注全部对方实例账号。
Pub-Relay是由Mastodon开发者开发的中继程序,由Crystal Lang编写,在联邦宇宙初期被广泛使用。但它稳定性不高,经常出现bug导致无法处理消息转发,而且实现语言不太流行,很多开发者不能对其进行有效修改,致使其功能匮乏,甚至不能对中继列表进行管理。
Activity-Relay则是一款新问世的由Golang编写而成的中继转发实现。它稳定性相对Pub-Relay更高,且扩展性更强,自带管理Cli可以进行实例屏蔽/移除等操作,还可以变为私有中继手动批准加入,唯一的美中不足就是没有提供统计API,迁移到Activity-Relay可以提高公共中继的整体稳定性及可用性。
Activity-Relay相较Pub-Relay性能开销有一定提升。
以DragonRelay为例,2C3G VPS CPU占用 1~2% → 10~15% (27订阅/2超大实例)
以DragonRelay为例,2C3G VPS CPU占用 1~2% → 10~15% (27订阅/2超大实例)
准备工作
根据Activity-Relay的官方Wiki编译安装,配置Systemd及反向代理程序(请跳过生成RSA密钥一步)。
迁移
需要迁移的内容有:
- 中继签名私钥
- 订阅列表
私钥
私钥直接使用原中继私钥即可,请注意如果原先私钥权限不是0600
请更改为0600
chmod 0600 /path/to/pem
订阅列表
由于两个程序实现均采用Redis作为持久数据库且key结构相似,我们可以直接使用一下脚本进行迁移。首先将原数据库复制到新的namespace以便发生未知错误时能够迅速回退:
# https://stackoverflow.com/a/26142152/15081893
source_host=localhost
source_port=6379
source_db=0
target_host=localhost
target_port=6379
target_db=1
redis-cli -h $source_host -p $source_port -n $source_db keys \*subscription\* | while read key; do # copy only subscription related keys
echo "Copying $key"
redis-cli --raw -h $source_host -p $source_port -n $source_db DUMP "$key" \
| head -c -1 \
| redis-cli -x -h $target_host -p $target_port -n $target_db RESTORE "$key" 0
done
随后执行以下命令更新数据库到Activity-Relay格式:
target_host=localhost
target_port=6379
target_db=1
redis-cli -h $target_host -p $target_port -n $target_db --scan --pattern relay:subscription:* | \
while read key; do
activity_id=$(redis-cli -h $target_host -p $target_port -n $target_db hget $key follow_id)
actor_id=$(redis-cli -h $target_host -p $target_port -n $target_db hget $key follow_actor_id)
redis-cli -h $target_host -p $target_port -n $target_db hmset $key activity_id $activity_id actor_id $actor_id
redis-cli -h $target_host -p $target_port -n $target_db hdel $key follow_id follow_actor_id state
done
重载你的反代程序,随后大功告成!
前端界面
前端界面可以参考https://github.com/dragonfly-club/dragon-relay配置。
我的pub-relay和Activity-Relay都是用Docker安裝的,請問
docker exec -it pub-relay_redis_1 /bin/sh
之後,再執行上面的腳本,然後將dump.rdb覆蓋/Activity-Relay/redisdata/dump.rdb
這樣的操作是否正確?可以用redis-cli 进行一下save保存操作 然后再直接copy dump.rdb
最好在activity pub redis 停止运行时覆盖
防止被redis定时保存覆写
謝謝!我再嘗試看看。不過負荷從1~2%上升到10~15%實在很嚇人,比ActivityRelay(為什麼名字這麼相近)龐大多了
ActivityRelay是什么
是从pub-relay → ActivityRelay 从1%~2%升至10~15%
不过都是瞬时最高值
ActivityRelay 是這個,fedi 裡佈署最多的:
https://git.pleroma.social/pleroma/relay/-/tree/master
我之前安裝的版本run不起來,最近有更新了
噢噢噢噢
这个我没太用过orz
Activity-Pub 是master/worker模型 可能在架构上不太一样导致占用不同的
具体的我也没太了解orz
换算成平均可能也差不多
pub-relay没有过高的瞬时负载
Google了一下,別人是用
head -c-1
解決new line的問題,但這個腳本已經有了这个脚本有什么🤔
是不是两个容器的redis版本不一致
这个脚本没有做保存工作呀
我第一次執行是成功的,但沒能運行起來就回溯了。第二次以後都會有這個錯誤,還沒到第二個容器裡操作
可以换回到第一个脚本备份的源数据库操作?