Tag: 系统设计

我在STEEM区块链上部署了ChatGPT机器人：系统设计: Steem区块链ChatGPT机器人，这个系统设计同时还跑了其它类型的机器人，原理就有一个读进程监听链上的操作，发现是相关的操作就把数据写到数据库中，然后由相关机器人的进程(比如ChatGPT)把数据再取出来，进行处理，然后再相应的写到数据库中的另一个表中。这里的数据库就类似中消息中间件 Message Queue，用来解耦不同的组件。 单点故障 Single Point of Failure，指得是系统中的一些零件如果损坏不能用了，整个系统也就变得不能用了。这里的读取进程就是单点故障，因为如果该进程崩溃了，再重新启用的时候也无法回溯过去区块链上的信息，这个进程实时监听链上的操作，如果错过了就是错过了。而这个系统设计其它的零件则没有这个问题，毕竟是处理数据库中的数据，进程崩溃会被自动重启，然后继续处理数据库中未被处理完的数据。 解决这个问题也不难，只要在不同的服务器上多跑几个读进程即可。不过这里需要保证数据库表里有唯一的限制，这样多台服务器在同时往同一数据库表格写数据的话只会有一条成功，而其它则会失败。 下面SQL给表格加个唯一的限制： alter table blockchain add unique key (block, ...); 英文：Avoid Single Point of Failures by Introducing Multiple Master Backup …

前几天, 把ChatGPT整合到了STEEM区块链上, 但最初的设计存在缺陷. 我发现其它机器人命令(!bing, !thumbup, !price, !info) 同样也有问题, 所以就借此机会重新设计重构了一下代码和结构. 这个DApps (ChatGPT机器人) 是使用JS (Node)编写的, 并由pm2管理器托管运行在一台云服务器上(VPS Server). STEEM区块链ChatGPT DApps设计缺陷 原先的设计: 进程(Blockchain)监听STEEM区块链上所有的帖子, 把满足条件的评论(含有 !ask 命令)的操作入数据库. 进程(ask) 或其他命令从MySQL中获取相应的记录, 并立即处理它们, 然后在同一进程中同步地发布到STEEM区块链. 这里会有一个问题, 确实来说, 大量并发会有问题. …

Cloudflare Worker 是和 Amazon Lambda, Google Function 类似的无服务器 Serverless 技术. 我们可以写一些代码(JS)部署到 CloudFlare 的网络节点中. 这项技术的好处是我们并不需要去维护服务器(减少运维成本), 而且通过Serverless技术很容易就可以把程序跑在成千上万的节点上 (较强的可扩展性). 负载均衡服务器(Load Balancer)用于把用户的请求重新分配(Route)到提供真正服务的源服务器(Worker). 我们可以通过负载均衡来实现水平扩展(Horizontal Scaling). 当然如果负载均衡只有一台服务器, 也是会有单点故障的 (Single Point of Failure). 如果通过CloudFlare Worker来搭建负载均衡, 这样我们的负载均衡服务器会被自动部署到成千上万的CloudFlare节点中 …