yukai08008的博客

Tornado：更适合专注于长连接和实时通信的场景，原生支持这些特性。FastAPI：更适合快速构建高性能API，也可以支持长连接，但需要依赖底层的异步框架。

继续实践ORM的使用现在看起来，选择ORM的确是更好的，它让代码看起来更清晰了，效率上也基本能够保持。

数据是数据库的内容，数据库负责存储、管理和组织这些数据。数据库为数据的存储提供了结构化的环境，并使数据的访问、管理和处理变得更加高效和安全。通过数据库系统，用户可以有效地管理大量的数据，并从中提取有价值的信息，从而支持各种应用和决策过程。人与数据库的交互方式多种多样，主要通过图形化工具、SQL 查询、编程语言、REST API 和自动化脚本等方式进行。选择哪种方式取决于用户的需求、技能水平和使用的场景。SQL类数据库的好处是普及率高，使用较为简单。在处理结构化数据时效率比较高，使用起来也比较简单。

Telegraf 是一个灵活且功能强大的数据收集代理，通过其丰富的插件系统，可以从各种数据源收集数据并发送到多种目标系统。它的轻量级和高性能使其成为监控、日志管理、物联网数据收集等场景中的理想选择。尤其是与 InfluxDB 结合使用时，它可以组成一个强大的时序数据收集和分析系统。Prometheus更适合实时监控和报警，尤其在云原生和微服务架构下的监控非常流行。InfluxDB则是一个通用的时序数据库，适合需要持久化、复杂分析、事件和日志处理的场景。

在大量数据处理任务下的缓存与分发这个算是来自顾同学的助攻+1，我有点java绝缘体的体质，碰到和java相关的安装部署总会碰到点奇怪的问题，不过现在已经搞定了。测试也接近了kafka官方标称的性能。考虑到网络、消息的大小等因素，可以简单认为kafka的速度是10万/秒级的。

暂时考虑的场景是单条数据处理特别复杂和耗时的场景。场景如下：要对一篇文档进行实体处理，然后再对实体进行匹配。整个处理包成了服务，在单线程处理增量的时候非常正常，但尝试进行并行调用的时候出现了问题。每次报错的时候都是显示,感觉像是服务端连接的问题。由于每一部分都可能是瓶颈，我没(时间)法准确定位问题所在，很有可能是同时起了5个实体识别，GPU的抢占导致的问题(负载经常在100%)。所以要解决的问题是：在保证逻辑正确的情况下，且有大量miss的情况下，如何尽快的完成业务上的任务。

开始比等待强这块其实我也不太熟，而且我也知道应该有更专业的做法其实连grafana我都准备好了，prometheus的镜像也准备好了，但是还没时间去细细弄。我想先快快整一版够用的（能让我依据这个数据进行调度）就行。

对于静态任务来说，一般可以事先分好大小均匀的若干block任务，这时候比较强调使用分布式系统进行快速处理；对于动态任务来说，主要按时间+区块大小划分。对于小的应用场景而言。

再补充一篇。之前连不上的原因也挺搞笑，大概是deepseek把我带偏了，应该是但是它教我关键是这个包似乎还真的存在…

所以，在IO端我一定不要害怕效率问题，而且实际上，并没有那么糟。sqlalchemy是ORM工具，这是典型的One思维工具。如果使用sqlalchemy ，而不是直接使用pymysql，在操作大量数据的时候，性能会下降多少。

1 协程用于worker级别，务求在单核上达到最高的IO并行2 线程用于player级别，确保多核并发worker3 除了主要的等待，开头和结尾可能还是有CPU开销。（至少json序列化也是常见的）

这是一个常见的使用场景，实测下来效果良好。

每个创新都会伴随着一系列的改变。在使用celery进行异步任务后，产生的一个问题恰好也是因为异步产生的。

发现对于异步(IO)还是太陌生了，熟悉一下。

最近做了几个实验，将结论梳理一下，方便以后翻看。

最近整体进展还比较顺利，不过也因为这样，好几个线头怎么继续平衡和推进需要稍微捋一下。

总算把这部分搞完了，实在有点长。总体上，实现了较为便捷的搭建方式，即使是新主机上也可以很快的部署配置。1 我会基于此，构造一个随时可启动的Stream，方便后续的逻辑接入2 对于某一项具体的工程，肯定是先构造数据流模型，然后使用这部分工具完成默认的连接。Stream2Stream通常可以用于跨主机间的数据共享，而 Stream2ClickHouse肯定是比较重要的一种数据持久化。之后还需要补充一些，例如Stream2Mongo,或者反过来，Mongo2Stream。

很久没有关注这方面的问题了，平时大部分时候还是做批量操作。在这种情况下(CPU密集),异步、协程这些意义就不大了，甚至可能进一步拖慢处理时间。但是在IO这一块的零碎处理是比较重要的，可以更快，且更省资源。很早的时候，曾经在执行规则引擎之前要分布的从mysql取数，结果处理时间特别慢；后来改用了asyncio和aiomysql，速度大幅提升，这给我了很深的印象：什么资源都没加，速度就是快了。后来我主要还是集中在批次处理数据下，每次都是万条的密集操作，这时候主要就用数据库本身的功能；

本次的数据流转任务基本上完成了，以数据流同步为例，验证了流转的有效性，并能确保在系统重启后，迅速恢复所有任务。1 重新搭建了flask-celery2 封装了对接flask-apscheduler的对象3 通过MongoEngine实现ORM操作4 使用状态机和规则来控制任务对象的状态改变总体上还是有些繁琐的，但总算完成了。之后就可以根据这套系统来完成大量的数据流转工作，接下来会基于此，先完成基本的S2S WorkMode。

之前已经完全跑通了任务调度，实现了S2S的流转。由于request请求用起来比较别扭，所以创建一个对象来进行便捷操作。

过去的几年，我已经构造了很多组件，从图的角度来看，完成了很多点。这些点的单点测试看起来都不错，但是因为没有连起来，所以无法体现系统价值。好比发动机的马力虽然大，但是没有传动轴，那就没法用起来。所以今年，虽然我还是会继续增加一些新的点，或者对某些点进行迭代，但是更重要的是将已有的点，连起来，完成系统功能。

1 可以参考langchain，进行增强。langchain本身还有agent的能力，继续融合后，是有可能完全不一样的。例如当你提到一个论点，agent可以自动查询实时数据，找到论据来support.2 ppt生成（及读取）。之前比较少用python操作ppt,现在看来，读和简单写应该是没问题的。

最初我认为负载均衡默认就带了健康检测的功能，nginx应该可以识别那些反向代理的服务器，那些有问题，然后避开它。实际上1.19版是没有的，没有这个模块时，负载均衡总是一视同仁的去调用那些已经挂掉的服务。只要有一个服务挂了，整个体验就是卡卡的。简单来说，就是要装一个check_module插件。传统办法好像要自己下载，然后重新编译啥的，看起来就很麻烦。然后我就想取个巧，但发现这个还要碰运气。

如果再来一次，我会把文件传到一个算力机，然后建一个clickhouse,数据全部写进去。然后将任务写到队列中，按照brick作为基本单位。然后租用更多的算力机，每个算力机上启动n个worker。worker工作时到队列中获取brick，然后根据brick从clickhouse中取数。处理完成后，数据写到结果表。写表前根据brick判断，是否可以插入。这样的话，估计手工的时间只需要2个小时，整体跑数时间应该短于6小时。1 可能会因为连接不稳，而导致处理中断。–不合适把租用机作为稳定的后端服务业源。

将复杂的规则（判定）作为一个函数调用。每个函数都要支持列表（多个元素）的并行处理。踩过的一个小坑：GlobalFunc使用了一个公网机的Redis做ROM，而GFGoLite使用m7本地的redis，导致了逻辑上看起来更新了，但是实际未更新。

1 RabbitMQ 和 RabbitAgent的建立。这使得其他机器可以不必要使用端口，非常适合超高计算传输比的任务。2 将原始数据通过rabbit agent 发布到任务队列3 将chatglm2-6b部署到算力租用机：测试了主流的三家autodl, anygpu和仙宫云，都是ok的4 在各算力机上启动worker进行处理5 将结果获取，然后存在本地的mongo没能成功完成的实践是在仙宫云使用nginx做负载均衡，简化worker的请求。结论：用llm来做任务成本还是比较高的。

通过rabbit_agent, 以接口方式实现对队列的标准操作，将pika包在微服务内，而不必在太多地方重复的去写。至少在服务端发布消息时，不必再去考虑这些问题。在分布式任务的情况下，客户端本身会启动一个持续监听队列的客户端服务，这些应该是容易通过简单的配置来实现的。在未来的应用上，我计划使用rabbitmq作为公网的消息队列，满足分布式计算的要求。例如，我部署了n个大模型，希望它们可以处理接口请求。

在国产大模型里，chatglm应该算是效果不错的，目前开源的三个版本都部署过。第一代的不太行，第二代，第三代的效果都还可以，但第三代对第二代似乎不是帕累托改善。在微调方面做了修改，但是显得比较乱。第四代之后不开源了，要调用官方的API，走向多模态了。考虑到我主要还是对中文进行处理，GPT系列目前能达到较好的使用效果（但缺点是串行，效率低），现在将这些版本进行一个整合及封装，供平时调用。

最近想重新上RabbitMQ，主要目的还是为了分布式任务调度。在Kafka和RabbitMQ两者犹豫了一下，还是觉得RabbitMQ好一些。在20年的时候有搞过一阵子的RabbitMQ,看了下当时的几篇文章，觉得其实想法一直没变过。介绍了丢包的问题，这个估计是我当时放弃使用这个的直接原因。现在想来挺逗的，完全是因为测试服务器ubuntu使用wifi连接不稳定导致的。文章参考RMQ官网，总结了7种队列工作模式。文章内还有使用pika进行测试的部分，我最主要使用模式2。

之前侧重在数据的IO、服务的并发响应以及复杂功能的实现方面。基本上架构方面不再是一个约束，只有在算法和规范上需要进一步完善。1 自动化运维。由于我的服务相对比较集中，所以可以自建一个微服务注册/监控/控制的服务。之前已经有过pilot了，所以应该没啥问题。2 分布式任务调度。使用flask aps + celery + rabbit_mq ,可以再做一个分布式的任务调度。

为了将GlobalFunc推向正常的应用轨道，构造一个功能简单的服务。

为了简化开发程序，特别是需要依赖全局数据的程序，例如：分布式任务需要知道当前可处理的任务；定时程序需要依据某个约束性全局变量。一个附带的好处是会大量减少对数据库产生的请求。

上一篇介绍了基于算力租用的方式部署chatglm3, 见；本篇接着看如何使用API方式进行使用。

完成了租用算力机的配置，包环境搭建，项目和模型文件拷贝已经基础的测试。下一步会搭建api服务进行进一步测试。

1 一对一的数据处理。适用数据处理场景。2 膨胀或者坍塌的数据处理。适用大数据实时计算（利用缓存层），也适用用于学习型的数据处理（建模、反馈、强化）3 时间序列处理。

想法变的真快本来是没打算用Tornado的，主要是想节约时间。但是现在看来不用还是不行：目前用gevent + flask部署的时候，启动多核的worker似乎存在问题。另外，有很多内部基础的数据服务，其实并不需要flask的各种组件。所以还是丢掉幻想，老老实实搭一个Tornado服务。

既要坚定锻炼成熟架构的道路，也要在合理的范围内重塑设计计算时序数据的特征，少不了“Rolling”类的操作。过去，直接采用pandas进行rolling，效率很不错，但是在实战应用时不太行。后来开发了ADBS，通过Mongo和Redis，在数据的持久化和吞吐上是没问题的。但是，对于全量的历史回滚计算遇到了问题。ADBS的架构将问题简化到了一个时隙，大大简化了逻辑，开发完成也即生产完成，这点很好；但是在大量的全量计算中，Mongo库还是碰到了“大频次”访问的问题。

这样就好了，比想象中的简单一些。未来可以通过服务(docker manager)来实现类似的批量启动分身的方法（再通过前端集成管理），这样就比较完美了。

我觉得已经快不太方便直接通过docker ps来查看运行中的容器了，另外就是批量的启动和停止分身比较麻烦，所以还是需要一个服务来替代手工操作。这只是其中一小部分容器。

这样一个日吞吐3000万以上的ABD就搭好了。正式投入使用时还需要修改sniffer，将数据从源拉过来，清洗后投向入队列。