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版本不一致
这个脚本没有做保存工作呀
我第一次執行是成功的，但沒能運行起來就回溯了。第二次以後都會有這個錯誤，還沒到第二個容器裡操作
可以换回到第一个脚本备份的源数据库操作？