寻梦友的博客

最近系统使用QPS增加，按照要求需要对核心接口进行压测，保证一定的QPS访问。配置测试人员进行一些压测，做一些CPU、内存等监控，以便了解各个接口的性能优化点。

问题现象实际项目中，在一个功能上线前，项目经理往往会询问，这个功能能支持多少用户同时在线使用？还有一些场景下，大家点击操作某些功能后，发现系统响应慢，或系统奔溃，为什么会这样？分析针对这些问题，其实就是要对核心功能进行压测，校验各个功能接口的极限。因此，哪些指标是影响压测的结果？为了更全面的分析压测结果，将从网络性能磁盘性能应用系统三个方面说明，在实际项目应用中，哪些指标是必须关注且真实能反馈出性能问题的。固态硬盘采用闪存存储技术，读写速度远超机械硬盘。

引用jar包Hutool 按功能模块划分为多个子包，常用模块包括：• core：基础工具模块，包括字符串处理、日期、数组、集合、IO、反射等功能。• crypto：加密解密模块，提供对称加密、非对称加密、摘要加密等多种算法实现。• http：HTTP 请求模块，简化 HTTP 请求的发起和响应处理。• json：JSON 解析模块，支持将 Java 对象与 JSON 互相转换。

1、一次性解析所有的文件内容(无论多大)，但例如word、pdf、excel等文件是有页、sheet概念，是无法区分2、对于复杂大文件，会导致内存溢出、泄漏、死循环等问题。

随着GPT大模型的盛行，传统文档的关键字匹配式搜索已不满足客户多样性的需求。深入理解客户问题灵活的和用户交流善于总结搜索内容等客户的核心诉求，是传统文档需要立刻解决的。(1).首先传统文档(docx、pdf、txt、excel、md等)需要多维度、精准的“信息提取”；(2).借助GPT AI能力，达到对搜索内容进行总结或理解客户问题；实际技术方案实现：(1).传统文档的“信息提取”，需要达到按页提取信息，且能够对图片OCR识别；

分析对应的mongodb表，表的总体数据量并不是很大，但单笔数据存储的较大(早期设计表的人考虑欠缺。对于超大规模的数据集，MongoDB提供了分片（sharding）和分区（partitioning）技术，可以将数据分布在多个服务器或磁盘上，通过并行查询来提升性能。针对上面的问题想象，结合实际表的存储大小、数据库服务器硬件性能等分析，在一次性查询较大数据集或返回较大数据集时，如何提高查询速度？：在每次分页查询时，使用上一次查询结果的最后一条记录作为下一次查询的起点，而不是简单地使用skip跳过大量记录。

因项目需要OCR识别能力，且要支持私有化部署。本文将对比市场一些开源的OCR识别工具，从中选择适合项目需要的OCR，且后续进一步研究/训练对应OCR模型。主要OCR识别有：Tesseract_OCR、PaddleOCR、EasyOCR、dddd_ocr、CnOCR备注说明：后面的图片测试使用如下。

自定义ES的DSL查询(dynamic ES Query Language)【DEQL】是针对非结构化信息加工、提取需求而设计的查询语言。DEQL可以任意组合搭配各类逻辑操作符，提供便捷、强大、复杂的查询功能。存在问题思考现实项目中，不同用户都要求根据的自身查询条件来获取想要的数据。但是，对搜索中间件(如ES)了解程度、对表结构的“黑盒”、对业务复杂性等等，这些问题导致搜索效果往往不尽如意，很难做到满足所有用户的要求。

案例背景最近项目遇到一个问题，用户在创作时，有文件流、图片、超链接、文本等信息产生，而这些信息的容量高达几十M【超大容量的信息】。由于历史技术方案局限性，将超大容量的信息存入mongodb/ES的一个字段中。导致查询时往往会内存泄漏或接口响应慢等现象。思考面对上面的问题，有这些思考：(1)、对于超大容量的文件该如何去存储？(2)、如果是超大容量的二进制信息流该如何存储？----基于超大容量的文件存储，在【(非结构化)文件管理案例】中有详细介绍。下面主要介绍“超大容量的二进制流的存储”。

目录一、前言二、sql语句优化三、索引优化3.1、建立并利用合理索引3.1.1、前缀索引3.1.2、全文索引3.2、避免索引失效而全表扫描【导致索引失效】四、表优化4.1、分区表----(事先预估就分区场景)4.2、分区表----(数据量暴涨后再考虑分区场景)4.3、同库分表----(事先预告就分表场景)4.4、同库分表----(数据量暴涨后再考虑分表场景)五、大数据平台方案六、具体实例梳理6.1、类似“用户userA点赞内容contentB的记录表”的场景6.2、类似“内容基本信息表”场景6.3、类似“订

前段时间线上系统出现一个严重的bug：一个表中插入两条一样的id记录信息(该字段未设置唯一主键)。查看了代码，第一印象是绝对不可能出现该Bug，不科学，怎么会出现两个相同的id记录呢？带着疑惑又仔细查看了代码，id的生成是SnowFlake雪花算法。大脑灵光一闪，这不就是分布式高并发下，SnowFlake雪花算法会出现重复id的问题。问题发现了，接下来就是“分布式高并发下，如何生成唯一id”的问题。UUIDJava自带的生成一串唯一随机36位字符串（32个字符串+4个“-”）的算法。

B公司的这套产品有多个应用系统服务【如appId1、appId2、appId3】，每个应用都有各自的业务应用场景，但都需要管理文档，那么就需要磁盘/内存容量。按照上面的要求，同一个公司，不同的组织架构的用户容量分配好，彼此是隔离。这里的技术关键点不是高并发，而是并发，即固定的容量，怎么保证同一时刻多个用户能够抢到容量资源，并且不能超过最大容量限制。根据实际的情况，如何保证并发下，各个应用服务的容量不超限制。A公司的不同组织分配不同的容量，并且不同组织使用产品的不同应用服务，做到分隔。

项目中遇到这样的一个需求：“一个docx文档，用户根据关键词能搜索定位到文档的哪一页”。docx文档主要有文本、表格、图片、附件这几类组合，为了达到高精度要求，表格、图片、附件等附带的内容也要能够搜索定位到，那么，对docx文档的每一页要收集上述几类的数据，以便后续功能扩展。以上就是这个需求的核心诉求，针对上面的问题，首先我们要解决的是：(1)、“如何精准的对docx文档按照页进行精准提取出文本、图片、表格等位置/信息”；(2)、对图片中文字信息进行提取；

前面一篇文章介绍了EasyExcel常见的导入导出的方式、以及如果合理持久化存储数据的思考。但是，在实际项目中，我们要考虑的是大内存、高并发场景，在这些场景下，怎么保证我们的功能正常运行。因此，针对文件导入导出，从“大内存、高并发”角度，有以下几点问题思考：(1)、对于大文件上传或多文件上传，如何保证系统性能和提高效率？(2)、大数据量导出，不能导出一个sheet、不能频繁IO操作，技术上如何实现？

最近项目中，需要对excel、csv等文件进行解析，并做相关的业务功能。在实际业务中，遇到不少难题：(1)、excel、csv格式未知，如果解析并合理存储数据？(2)、对于大文件上传或多文件上传，如何保证系统性能和提高效率？本篇文章，我们主要介绍的是EasyExcel如何解析各类格式的文档，并合理存储数据的技术方案思路。

GPT，全称Generative Pre-trained Transformer ，中文名可译作生成式预训练Transformer。ChatGPT是由一个叫OpenAI的机构开发的，它使用了一种叫做GPT的技术，这种技术可以让它从互联网上学习大量的文字信息，然后根据文字之间的关联性概率性来生成新的文字。因此，它的局限性是可能会生成不准确或不合适的答案。相信未来技术发展，GPT的准确性会大幅度提高，会应用到各领域/场景，并且能够与其他技术或平台集成。

目前接触的项目系统架构如上，属于分布式微服务架构。规模、QPS等特点决定它算不上大规模高并发高性能企业级的分布式微服务架构，因此一些业务场景要求的技术栈选型也是因地制宜。当前项目要求，需要对应日志管理分析能力，这里不仅仅需要收集/搜索系统日志(info、warn、error等)，而且还需要根据不同业务操作要求，来处理特别场景的日志，如接口调用记录明细、接口调用预警【设置单个接口调用次数阈值、单个接口被单个用户调用次数阈值等等】、日志报表统计图等。流行的ELK日志平台，为什么不选择？

最近接触一个平台架构的讨论，公司需要一个非结构化数据中台，理念是能够满足存储随时变换的非结构化数据，另外引入低代码思想。由于非结构化数据是未知的，不同业务的数据是不同，为了更好的使用，低代码就需要一种方案，在尽量不开发代码下满足相关需求变化，快速迭代上线。

由于项目需求，会存储大量的非结构化文件，因此对非结构化文件管理是值得思考的问题。结合自身参入项目的方案设计思路，针对“如何管理非结构化文件”，有如下的思考：(1)、文件上传的方式有哪些？(2)、完整的文件如何去存储？方便后续的下载、预览等(3)、文件附属管理信息如何获取？如文件大小、类型、名称、总页数等等(4)、如何定位到文件具体哪页？如由关键字搜索到属于文件哪一页并且相关数据要输出(5)、一份文件中有文字、图片、表格等元素信息，如何提取？

写这篇文章前，有必要说明下。自己搭建的只是非分布式的轻量级任务调度平台，它和现在网上已经成熟的quartz、xxl-job等是没法对比的【不是说功能满足不了，而是适应分布式场景上是有差距的】。撰写这篇文章，主要记录在实现业务功能基础上，自己如何去思考？如何去可拓展的实现？如何做到向其他项目进行快速推广使用？----能力有限，不喜欢勿喷！对于任务调度类有很多，通过对比分析【可参考任务调度类对比】，最后选择了ThreadPoolTaskScheduler类来实现。