实现多数据源配置及动态切换背景最近在MySQL大体量数据冷热归档项目的开发过程中，需要从8+数据源的不同业务库（源库、归档库）中，对数据进行迁移操作，动态查询新的源库数据源信息并切换到该数据源所迁移的归档库做相应的查询、插入操作，翻阅了网上很多资料都是简单的对多数据源的整合，并没有涉及到多数据源配置及动态切换的案例 目标 在迁移配置表中，根据source_datasource、target_datasource字段在代码中动态切换对应的数据源信息，将源表数据迁移至归档表数据 详细实现方案一1、pom文件配置项目所需的依赖 123456789101112131415161718192021222324252627282930313233343536373839 <!--web模块依赖--><dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId></ ...

日志系统完善方案背景现状当前业务环境没有统一的日志输出格式，日志文件只能通过HTTP下载，运维人员处理效率低，需要将服务接入日志系统规范及适配性改造等（约150个微服务）；服务增加日志采集（约100个微服务） 目标通过完善日志系统集中收集日志，升级日志链路ID规范，通过打通日志系统链路ID和听云系统链路ID；提高运维效率，缩短问题定位时间由原来的2天降低至1天内 技术栈选择 采集层：Filebeat（轻量级日志采集） 缓冲层：Kafka（高吞吐消息队列，削峰填谷） 处理层：Logstash（日志解析、过滤、富化） 存储层：Elasticsearch（分布式搜索与存储） 展示层：Kibana（可视化分析与仪表盘） 现状与升级后对比总览 系统设计 应用程序日志采集设计 业务集群变更： 在启动命令中加入听云Agent，日志输出时调用链路ID。 统一日志输出模板，升级服务接入日志规范。 日志系统收集全部业务日志。 修改本地存储日期策略，节省服务器磁盘空间。 提供日志收集级别配置，根据实际情况调整日志收集级别。 日志滚动生成：定义并规范日志输出的统一格式，确保日志按一定规则滚动生成。 Fi ...

车辆综合查询报表接口优化背景： 通过日志平台对车辆综合查询接口的响应时间进行分析，发现当前接口的平均响应时间比较长，为了提高用户使用的体验，需要对接口进行优化 目的： 整理用户权限和组织权限之间的区别和涉及到的表信息 基础节点信息的表改造，添加排序字段，优化查询速度 相关接口： /car/queryMonitorList /optimize/queryFuelCarList 对接口调用链路分析： 分析发现，主要还是SQL层面的响应时间比较长，所以从SQL进行优化 流程： 首先调用车辆综合报表方法xxQueryFuelCarList 进入查询车辆车次计数xxCarAllCount 遍历车辆节点表xx_Node_CarInFo_Car找到对应节点 对应节点车辆的基础信息表xx_Node_relationship 基础节点SQL 123456789101112131415-- 执行查询，查找根节点及其所有后代节点SELECT id, nameFROM ( SELECT t1.id, t1.pid, ...

大体量业务数据表迁移方案全量+增量混合迁移 背景分析对大体量业务数据表和归档数据表字段进行查询后，整理出所有非create_time的表如下所示： 大体量业务数据表中非create_time的表: hy_business_platform_log (LOG_DATE) ota_eol_message_log (req_time) 归档数据表中非create_time的表: driving_behavior_xx（create_date） archive_driving_behavior_xx（create_date） 由于大部分表都有create_time字段，因此全量和增量迁移都基于create_time进行数据分片，具体执行方案如下。 全量迁移：1、数据导入：将临时存储区的全量数据迁移至新建的归档数据库。 创建迁移配置表 1234567891011CREATE TABLE migration_config ( id BIGINT AUTO_INCREMENT PRIMARY KEY, source_db_name VARCHAR(128) NOT NULL C ...

什么是ReentrantLock ？ReentrantLock 其实就是基于 AQS 实现的一个可重入锁，支持公平和非公平两种方式。 内部实现依靠一个 state 变量和两个等待队列：同步队列和等待队列。 利用 CAS 修改 state 来争抢锁。 争抢不到则入同步队列等待，同步队列是一个双向链表。 条件 condition 不满足时候则入等待队列等待，是个单向链表。 是否是公平锁的区别在于：线程获取锁时是加入到同步队列尾部还是直接利用 CAS 争抢锁。 参考图片： 扩展CAS操作CAS 是一种硬件级别的原子操作，它比较内存中的某个值是否为预期值，如果是，则更新为新值，否则不做修改。 工作原理： 比较（Compare）：CAS 会检查内存中的某个值是否与预期值相等。 交换（Swap）：如果相等，则将内存中的值更新为新值。 失败重试：如果不相等，说明有其他线程已经修改了该值，CAS 操作失败，一般会利用重试，直到成功。 自旋锁自旋锁（Spinlock） 是一种轻量级锁机制。线程在获取锁失败时不会立即进入阻塞状态，而是会在循环中反复尝试获取锁，直到成功。 这种方式避免了线程的上下文切 ...

LM Studio 介绍：LM Studio是一款能够本地离线运行各类型大语言模型的客户端应用，通过LM Studio 可以快速搜索所需的llms类型的开源大语言模型，并进行运行。 通过使用LM Studio 在本地运行大语言模型可以更加快速的运行流畅的提问，并在独立的环境中保障数据不被监听和收集。 特点：本地、独立、离线 官网：https://lmstudio.ai/ 参考文档：docs 步骤：首先进入官网Download下载页面，选择自己电脑的操作系统点击下载安装包 下载完成之后根据步骤安装好后双击进入 点击右上角的Skip onboarding跳过 接着点击UI界面中间的“Select a model to load”，开始搜索模型，第一次搜索会显示No result found，列表可以看到，但无法进行下载模型。这个时候不要慌，因为https://huggingface.co/ 在国内是无法访问的 在软件内部获取模型的是通过https方式来访问的，全局代理也没有过去，因此科学上网也用不了 这时候只能用国内的同步的镜像： hf-mirror.com，用于替换镜像 huggi ...

如何避免用户重复下单（多次下单未支付，占用库存）场景回顾 在稀有商品抢购或秒杀场景中，一个用户多次下单未支付可能是恶意锁库存或损坏其他用户的权益，因此需要避免用户重复下单。 1）首先前端需要进行按钮控制 在用户点击“下单”按钮后，可以通过前端控制按钮状态，比如变为“处理中”或“请稍等”，避免用户在等待过程中多次点击按钮，导致重复下单请求发送到后端。但是前端的操作无法完全避免重复请求，因此需要与后端的幂等控制结合，以确保不会因多次点击创建多个订单。 2）在每次下单请求中生成一个唯一的requestId或token 用户进入订单页面前，前端会先请求后端生成这次请求的唯一的requestId或token，然后在每次下单请求中带上这个唯一的requestId或orderToken。这样后端可以通过检测该标识是否已存在，来决定是否创建新订单。这样，无论用户重复点击几次下单按钮，仅会创建一次订单。 以上两步能阻挡绝大部分用户正常操作下的重复下单行为，如果一些用户通过 api 请求，或者后退页面再次点击下单进入，还是可以重复下单，不过一般这种设计已经可以杜绝稀有商品抢购或秒杀场景的恶意锁库存了， ...

白嫖华为云400元代金卷各位码友们，白嫖ESC服务器的活动来啦，可以免费领取1年的华为云服务器，给你的项目上线或者搭建私人博客~ 具体奖励： 两个都选代金卷的话还是很香的 给大家看看之前白嫖代金卷领的服务器： 之前活动领取的包，皮质，质量还是不错的 前置条件首先点击报名链接报名：https://edu.huaweicloud.com/signup/c586933f7a12484aa2afb4696d2629e8?medium=share_kfzlb&invitation=d2139abb8e254557b3dd2af10685bdd9 具体步骤一：完成任意云实验 打开报名链接，找到云实验的实验列表： 完成五个实验其中一个就可以抽奖，这里我选的是最后一个： 点击开始实验之后，根据窗口左侧的实验手册按步骤来就能过，大概用时10分钟，相信聪明的码友们都没问题o.o 实验完成后点击链接抽奖：https://survey.huaweicloud.com/survey/#/qtn?id=7af9f98b8b904c2fb8603742bd112b5d 这里选择自己做的实验 ...

需求背景对于有会员系统或付费机制的项目，为了保证单个用户的账号权益不会被滥用，并且提升系统的安全性，我们通常会限制 单个账号在同一时间只能在一台设备上登录。为此，我们需要给系统添加共享账号的检测能力 系统设计该需求建立在使用 Cookie/Session 登录的情况下，使用 token 登录不完全适用 业务流程分析假设在已有的项目中，我们已经集成了 Spring Session 进行登录。让我们先来梳理一下现在的流程:1.前端发送登录请求给后端，传递用户名、密码等参数。2.后端校验登录参数是否合法，如果没问题，则将用户登录态保存到 Redis(可以使用 spring-session-data-redis 库自动实现)，并且将 cookie 返回给前端。3.之后的请求会携带 Cookie，后端可以根据 Cookie(Session)从 Redis 获取到已保存的用户登录态，从而判断当前用户是否登录、已登录用户的信息等。 如图所示： 核心实现思路就上述的登录逻辑而言，我们没有采取任何措施去限制同一账号只能在单个设备登录，理论上一个账号就可以被任意个用户同时共享使用。这可能会导致 ...