Tag: 系统设计
视频观看地址 同步到以下地址，还有微信视频号和小红书。 油管：Youtube B站：Bilibili 西瓜：Xigua 新挖一个坑，教媳妇系统设计，第1课讲的是数据分片/切片，也就是把数据按怎么样的方式存放到不同的服务器上。 随着数字化时代的快速发展，数据无疑成为了企业最宝贵的资源之一。然而，数据的快速增长也带来了存储和处理的挑战。在这个背景下，“数据分片（Data Sharding）”成为了解决大规模数据管理问题的关键技术之一。本文将深入探讨数据分片的不同类型和实现方法，并着重讨论水平分片和垂直分片的具体策略。 水平分片 (Horizontal Sharding) 水平分片是指将一个大表中的行分割成较小的片（Shards），每个片在物理上可以分布在不同的数据库服务器上。这种方法的主要优点是能够提高查询性能和可扩展性，因为操作可以在多个服务器上并行处理。水平分片可以根据不同的分片策略来实现，常见的有： 基于键的分片 (Key-based Sharding)：在这种策略中，数据根据分片键的值被分配到不同的片。分片键通常是数据表中的一个或多个字段，通过散列函数，可以将行均匀地分布到多个片中。这种方法的一个挑战是选择合适的散列函数，以避免数据热点问题。 基于范围的分片 (Range-based Sharding)：此方法按照指定范围将数据分配到不同的片中。例如，客户记录可以根据姓氏的字母顺序或客户ID的范围进行分片。虽然这种方法可以很容易地实现和理解，但如果数据分布不均，可能会导致某些片过大，影响系统性能。 基于字典的分片 (Dictionary-based Sharding)：在这种策略中，维护一个查找表或字典，指明哪些行属于哪个片。这种方法在数据分布不容易预测或经常变化的情况下特别有用，因为字典可以动态更新。但是，管理和更新字典可能会增加额外的复杂性和开销。 垂直分片 (Vertical Sharding) 垂直分片涉及将一个数据库表中的列分割开来，不同的列（通常是功能相关的列组）存储在不同的数据库或服务器上。这样不仅可以减少每次查询需要扫描的数据量，还能根据应用的需求优化数据的存储。垂直分片的主要挑战在于跨多个数据库或服务器的事务一致性和数据整合。 总结 数据分片是一种强大的技术，可以帮助企业有效管理大规模数据集。选择合适的分片策略需要综合考虑数据的特性、应用的需求以及系统的架构。通过合理的设计和实现，数据分片不仅能够提升系统的性能和可扩展性，还能确保数据管理的灵活性和高效性。在未来的数据驱动世界中，掌握和应用数据分片技术将变得越来越重要。 数据分片 (Data …
我在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节点中 …
