本文最后更新于 2024-08-09，文章内容可能已经过时。

在课程预约的时候，用户暂存即将过期，那一刻用户刚好提交了，怎么办？

问题应该是想问自动取消在过期那一刻会自动去修改数据库表单状态为过期，但用户新提交的数据会修改状态为预约成功，此时可能会发生冲突。

  • 乐观锁CAS(compare and swap)：在更新数据库时检查版本号，确保数据在读取和写入之间没有被修改。如果检测到冲突，可以回滚事务并通知用户重新提交。

  • 确保用户提交和自动取消操作都在数据库事务中执行。这可以确保操作的原子性，即要么完全执行，要么完全不执行。

  • 如果发生冲突，系统应该能够捕获异常并通知用户。例如，可以告知用户“由于系统错误，您的预约未能成功提交。请重新尝试。

项目上需要导入一个几百万数据 excel 文件到数据库中，有哪些注意点？

假设有一个 1G 大的 HashMap，此时用户请求过来刚好触发它的扩容，会怎样？怎么优化？

老师想要知道学校过去七天/一个月/一年消费top50

老师想要知道当天消费排行/图书馆在馆时长排行

这个项目的性能是否有遇到瓶颈？如何优化项目？

你在项目中使用 Redisson 分布式锁解决了接口幂等性的问题，请简要介绍一下 Redisson 分布式锁的使用场景和实现原理。

你在用户登录功能中提到使用 Hash 代替 String 存储用户信息，这样的做法有什么好处？在实际应用中，Hash 与 String 存储方式有哪些区别？

你在项目中是如何实现 Redis 缓存的？选用了哪种 Redis 数据结构？

待整理

实时性问题：通过doris解决

即时性问题:

  1. 不需要复杂处理的，通过定时任务+数据库查询的，

设计了三个表reports(结果存放) source(执行条件) extends (数据源) cron(定时任务调度机制)

exports包含：key,name,value(存放json结果),result_type(根据不同类型进行返回)

source包含：key,reportId,param,extendId,result_type(根据不同类型查询,考虑返回json还是值)

extends包含：key,type,info(json格式数据源)

cron包含：key,pool(并发数量).rhythm(调度策略)

流程：

初始化

读取extends的数据源到client连接池中，通过

遇到问题：source

  1. 需要复杂查询，通过数据库+缓存+redis查询

缓存一些热点数据,比如当天进出门禁数据

课程数据优化：

使用bigint存放上课周次/时间等，通过十进制数右移1位，获取对应的二进制数，每一位代表每一周的课程。

一学期就18周课程，2^17是131072，一般最后一周也不会有课。

这样子就可以通过一条数据表示课程的上课时间/节次等，相比于一行一周还要对应一天的节次，冗余量大大减少。

原始数据是1-18字符串，性能优化，一开始用的+号，比较耗内存，后面使用string.builder

mysql 自增id 越界，如何检测和避免

由于数据频繁增删，导致为 int 类型的字段自增到上限，丢失了数据.

使用更大的数据类型

  • BIGINT UNSIGNED：在MySQL中，你可以将自增ID的字段类型设置为BIGINT UNSIGNED，这样可以提供高达19位的数字范围（从0到18446744073709551615），这对于绝大多数应用来说已经足够大，几乎不可能在可预见的未来内达到上限。

2. 分布式ID生成策略

  • UUID：虽然UUID不是自增的，但它提供了一种全局唯一的标识符，适用于分布式系统。UUID的缺点是它们占用的空间比整数大，且无序，可能影响数据库性能（尤其是在索引和排序方面）。

  • 雪花算法（Snowflake）：这是一种由Twitter开发的分布式系统中生成唯一ID的算法。它能够在分布式系统中生成趋势递增的ID，同时保持全局唯一性。雪花算法生成的ID是一个64位的整数，其中包含了时间戳、数据中心ID、机器ID和序列号等信息。

3. 定期检查与规划

  • 监控ID使用情况：定期监控自增ID的使用情况，了解ID的增长速度和剩余空间，以便提前规划。

  • 数据归档与清理：对于不再需要的数据，进行归档或清理，以减少对ID空间的占用。

4. 逻辑分区

  • 分片：在数据库层面进行分片，每个分片使用独立的ID空间，从而避免单一ID空间的限制。

5. 评估业务需求

  • 评估增长潜力：根据业务增长潜力，合理评估ID空间的需求，选择适当的数据类型。

6. 备份计划

  • 数据迁移计划：如果预计会达到ID的上限，制定数据迁移计划，将数据迁移到新的数据库实例或表，并重置ID计数器。

总之，避免自增ID越界需要综合考虑数据库类型、业务需求、系统架构和未来发展等多方面因素。在大多数情况下，通过选择适当的数据类型和采用分布式ID生成策略，可以有效地管理ID空间，避免越界问题