网站建设中html模板上海网站建设zj kt

网站建设中html模板,上海网站建设zj kt,创建网站花钱吗,西安网页设计公司推荐1.设计一下过年的时候支付宝抢红包问题#xff0c;如何开发#xff1f;抢红包功能分为发红包和抢红包两大环节#xff0c;流程如下#xff1a;用户发红包 → 红包信息初始化#xff08;Redis数据库#xff09;→ 用户抢红包 → Redis原子校验金额分配 → 实时返回结…1.设计一下过年的时候支付宝抢红包问题如何开发抢红包功能分为发红包和抢红包两大环节流程如下用户发红包 → 红包信息初始化Redis数据库→ 用户抢红包 → Redis原子校验金额分配 → 实时返回结果 → 异步落库消息通1.1、发红包环节设计支持两种常见红包类型需在发红包时指定普通红包固定金额每个抢到的用户金额相同拼手气红包随机金额总金额固定单个金额由算法动态分配。发红包时需生成核心信息并同步写入Redis抗高并发和数据库持久化Redis 存储核心用 Hash 结构存储红包元数据keyred_packet:{红包ID}Hash 字段含义total_amount总金额单位分避免浮点误差remain_amount剩余金额total_count总个数remain_count剩余个数type红包类型1 普通2 拼手气creator_id发红包用户 IDcreate_time创建时间同时用 Set 结构keyred_packet_users:{红包ID}记录已抢用户 ID防止重复抢。数据库存储持久化同步写入red_packet表记录红包元数据保证数据最终一致性。拼手气红包金额预分配 / 实时分配推荐实时分配避免预分配占用内存抢红包时通过算法动态计算当前用户的金额需满足单个金额≥0.01 元1 分剩余金额能覆盖剩余个数的最小金额remain_amount ≥ remain_count * 1。分配算法单个金额 随机值 ∈ [1, (remain_amount - (remain_count - 1)) * 2]注上限设为剩余金额的2倍避免后续用户金额过低1.2.抢红包环节设计高并发核心抢红包是高并发场景过年峰值 QPS 可达数十万需通过Redis 原子操作 异步落库实现高性能。1.2.1 核心逻辑Redis Lua 脚本用 Lua 脚本保证抢红包操作的原子性避免超抢、重复抢脚本流程lua-- 1. 校验红包是否存在、是否还有剩余 local red_packet redis.call(HGETALL, KEYS[1]) if #red_packet 0 then return 0 end -- 红包不存在 local remain_count tonumber(redis.call(HGET, KEYS[1], remain_count)) if remain_count 0 then return 1 end -- 红包已抢完 -- 2. 校验用户是否已抢过 local has_grabbed redis.call(SISMEMBER, KEYS[2], ARGV[1]) if has_grabbed 1 then return 2 end -- 重复抢 -- 3. 分配金额普通/拼手气 local total_amount tonumber(redis.call(HGET, KEYS[1], total_amount)) local remain_amount tonumber(redis.call(HGET, KEYS[1], remain_amount)) local red_type tonumber(redis.call(HGET, KEYS[1], type)) local amount 0 if red_type 1 then -- 普通红包固定金额 总金额/总个数 amount total_amount / tonumber(redis.call(HGET, KEYS[1], total_count)) else -- 拼手气红包动态计算金额 local min 1 local max (remain_amount - (remain_count - 1)) * 2 amount math.random(min, max) end -- 4. 扣减剩余金额、个数记录用户 redis.call(HINCRBY, KEYS[1], remain_count, -1) redis.call(HINCRBY, KEYS[1], remain_amount, -amount) redis.call(SADD, KEYS[2], ARGV[1]) -- 返回抢到的金额单位分 return amount1.2.2. 接口层处理前端请求防抖限制用户 1 秒内最多发送 1 次抢红包请求避免重复提交后端接口接收请求后直接调用 Redis Lua 脚本同步返回抢红包结果成功 / 失败 / 已抢限流通过网关如 Nginx或分布式限流组件如 Sentinel限制单 IP / 单用户的请求频率防止恶意刷红包。1.2.3. 异步落库与通知抢红包成功后通过 ** 消息队列如 RocketMQ** 异步处理后续流程写入红包明细将用户 ID、抢到金额、红包 ID 写入red_packet_detail表余额变更更新抢红包用户的余额若红包是余额支付消息通知通过推送服务如 WebSocket、APP 推送告知用户抢红包结果。1.3、红包过期退款设计红包默认 24 小时未抢完自动退款通过Redis 过期键通知实现实时触发发红包时给 Redis 的红包 Key 设置 24 小时过期时间Redis 触发过期通知后后端监听服务接收事件执行退款计算剩余金额退还至发红包用户的账户更新red_packet表的状态为 “已退款”并记录退款时间清空该红包对应的 Redis 用户 Set。1.4、数据一致性保障Redis 与数据库对账定时任务如每小时对比 Redis 和数据库的红包剩余金额、个数若存在差异以 Redis 数据为准修正数据库消息队列可靠性使用事务消息或死信队列保证异步消息不丢失金额精度所有金额以 “分” 为单位存储和计算避免浮点数精度误差。1.5、架构支撑分布式部署多实例 负载均衡如 Nginx分担流量Redis 集群主从 哨兵保证 Redis 高可用避免单点故障监控告警实时监控 Redis QPS、接口响应时间、消息队列堆积量异常时触发告警。3. synchronized 锁升级过程及升级为重量级锁的原因锁升级过程无锁状态对象未被任何线程锁定。偏向锁当一个线程首次获取锁时将对象头的 “偏向线程 ID” 设为当前线程 ID后续该线程再次获取锁时无需 CAS 操作直接通过线程 ID 匹配即可。轻量级锁当其他线程尝试获取偏向锁时偏向锁升级为轻量级锁。线程会在自己的栈帧中创建 “锁记录”并通过 CAS 将对象头的 “Mark Word” 替换为锁记录的指针若 CAS 成功则获取锁失败则自旋尝试。重量级锁当自旋次数超过阈值或自旋线程数过多轻量级锁升级为重量级锁。此时依赖操作系统的互斥量Mutex实现线程会进入阻塞状态。升级为重量级锁的原因轻量级锁的自旋会消耗 CPU 资源当线程竞争激烈自旋失败次数多时自旋的性价比降低转而使用操作系统级别的阻塞机制重量级锁避免 CPU 空转。4. 迷宫问题最短路径的解法采用广度优先搜索BFS求解因为 BFS 能保证找到 “最短路径”每一步是等权的。步骤初始化队列将入口坐标入队并标记为已访问。每次从队列取出一个坐标遍历其上下左右四个方向的相邻坐标。若相邻坐标是 “桥1” 且未被访问则记录路径长度当前长度 1并将其入队、标记为已访问。当访问到出口坐标时返回当前路径长度即为最短路径。5. 锁的三大特性及保障方式、内存屏障原理锁的三大特性原子性保障操作不可分割要么全部执行要么全部不执行。保障方式通过锁的排他性如 synchronized、ReentrantLock同一时间仅一个线程执行临界区代码。可见性一个线程对共享变量的修改其他线程能立即感知。保障方式锁释放时会将工作内存的修改同步到主内存锁获取时会从主内存加载最新值如 synchronized 的 “解锁 - 同步主存”、volatile 的内存可见性。有序性保障指令执行的顺序符合预期避免指令重排序。保障方式锁会禁止临界区内的指令重排序如 synchronized 的内存屏障、volatile 的 “禁止重排序” 规则。内存屏障原理内存屏障是一组 CPU 指令用于限制指令的重排序并强制刷新缓存。分为读屏障Load Barrier和写屏障Store Barrier读屏障强制从主内存加载最新数据到工作内存保证后续读操作能获取最新值。写屏障强制将工作内存的修改同步到主内存保证之前的写操作对其他线程可见。JVM 通过内存屏障实现 volatile 的可见性与有序性以及 synchronized 的内存语义。6. 排序方式、时间复杂度及快排实现常见排序方式及时间复杂度排序算法最好时间复杂度平均时间复杂度最坏时间复杂度空间复杂度冒泡排序O(n)O(n²)O(n²)O(1)选择排序O(n²)O(n²)O(n²)O(1)插入排序O(n)O(n²)O(n²)O(1)快速排序O(nlog₂n)O(nlog₂n)O(n²)O(log₂n)~O(n)归并排序O(nlog₂n)O(nlog₂n)O(nlog₂n)O(n)堆排序O(nlog₂n)O(nlog₂n)O(nlog₂n)O(1)快速排序的实现基于 “分治思想”步骤为选基准从数组中选一个元素作为基准如中间元素、随机元素。分区将数组中小于基准的元素放到基准左侧大于基准的放到右侧。递归对基准左侧和右侧的子数组分别重复上述步骤直到子数组长度为 1已有序。快速排序的时间复杂度最好 / 平均O (nlog₂n)分区均匀时最坏O (n²)分区极不均匀如有序数组选首尾元素为基准。7. 二叉树、平衡二叉树、红黑树的区别二叉树每个节点最多有两个子节点左、右子树无其他限制。可能出现 “斜树”退化为链表查询时间复杂度 O (n)。平衡二叉树AVL 树是二叉搜索树的一种要求任意节点的左右子树高度差不超过 1。通过旋转左旋、右旋、左右旋、右左旋维持平衡查询时间复杂度 O (log₂n)但插入 / 删除时旋转操作频繁效率较低。红黑树是二叉搜索树的一种通过以下规则维持 “近似平衡”节点是红色或黑色根节点是黑色所有叶子节点NIL是黑色红色节点的父节点必须是黑色从任意节点到其所有叶子节点的路径包含的黑色节点数相同。红黑树的高度不超过 2log₂(n1)查询 / 插入 / 删除的时间复杂度均为 O (log₂n)且旋转操作少于 AVL 树实际应用更广泛如 HashMap 的底层结构。8. MySQL 索引采用 B 树而非 B 树、红黑树的原因MySQL 索引选择 B 树而非 B 树、红黑树的核心原因是适配磁盘存储的特性降低 IO 开销磁盘 IO 是数据库性能瓶颈具体差异如下8.1、对比红黑树解决 “树高度过高导致 IO 次数过多” 的问题红黑树是二叉树每个节点仅存储 1 个索引键 数据树的高度会随数据量快速增长如百万级数据的红黑树高度约 20 层。而 MySQL 索引存储在磁盘中单次 IO 仅能读取一个磁盘页通常 16KB若用红黑树查询需执行约 20 次磁盘 IO开销极大。B 树是多叉树每个节点可存储大量索引键如 16KB 的页可存上千个 int 类型的索引键树的高度仅 3~4 层查询仅需 3~4 次磁盘 IO大幅降低了访问成本。8.2、对比 B 树优化 “节点存储效率与查询特性” 的问题B 树的非叶子节点同时存储索引键 数据而 B 树的非叶子节点仅存索引键叶子节点存储数据并通过链表连接两者差异适配了数据库的查询需求节点存储效率更高B 树非叶子节点因存储数据单个节点能容纳的索引键数量少导致树的层数更多、IO 次数增加B 树非叶子节点仅存索引键单个节点可容纳更多索引键层数更少IO 效率更高。范围查询更高效B 树的叶子节点通过双向链表连接范围查询如WHERE id BETWEEN 100 AND 200可直接遍历叶子节点无需回溯上层B 树的范围查询需频繁回溯父节点性能远低于 B 树。查询性能更稳定B 树的所有查询都需到叶子节点时间复杂度稳定为O(logn)B 树可能在非叶子节点直接找到数据查询时间复杂度不稳定而数据库需保证稳定的查询延迟。综上B 树通过 “多叉结构降低高度”“非叶子节点仅存索引键”“叶子节点链表化” 等设计完美适配了磁盘存储的 IO 特性同时满足了数据库的单条查询、范围查询的性能需求。9. 线程池线程数设置的原因线程池线程数需匹配任务的资源占用特性CPU 密集型操作任务以 CPU 计算为主如复杂运算线程执行时极少阻塞。若线程数过多CPU 会因频繁上下文切换消耗额外资源抵消计算效率。因此线程数设为N1N 为 CPU 核心数N 可充分利用 CPU 核心1 是预留备用线程避免个别线程短暂阻塞时 CPU 空闲。IO 密集型操作任务频繁等待 IO如文件读写、网络请求线程多数时间处于阻塞状态不占用 CPU。因此线程数设为2N更多线程可利用 IO 等待的空闲时间在部分线程阻塞时其他线程能继续执行提升整体吞吐量。10. 年龄修改后读取异常的原因及解决方案原因分析该现象是并发场景下的数据一致性问题核心原因包括并发更新丢失写覆盖两次修改请求并发执行时线程 2改 20先读取旧值线程 1改 19写入 19 后线程 2 仍基于旧值写入导致 19 覆盖 20或请求处理顺序与发送顺序不一致如第二次请求先到达但后执行。事务隔离级别过低若数据库隔离级别为 “读未提交”读取操作可能获取到其他事务未提交的脏数据如第一次修改的 19 未提交时被读取。缓存一致性问题读取操作命中了未及时更新的旧缓存未获取到最新的 20。解决方案乐观锁控制并发在用户表增加版本号字段修改时通过版本号校验sqlUPDATE user SET age 20, version version 1 WHERE id ? AND version ?版本号不匹配则重试避免写覆盖。悲观锁串行修改修改时对用户行加锁确保同一用户的操作串行执行sqlSELECT * FROM user WHERE id ? FOR UPDATE; -- 行锁 UPDATE user SET age 20 WHERE id ?;优化事务与缓存将数据库隔离级别调整为 “读已提交” 及以上避免脏读修改数据后立即失效对应缓存确保读取命中最新数据。请求串行化基于用户 ID 加本地锁 / 分布式锁保证同一用户的请求按顺序处理。11.ShardingJDBC 的情况下如何设计分表它的查询逻辑优化逻辑新建表要注意什么在 ShardingJDBC 的分表场景中核心围绕分片键设计、路由效率、数据一致性展开以下是具体的分表设计、查询逻辑、优化及建表注意事项一、分表设计分表的核心是 ** 分片键Sharding Key** 的选择与分片策略的匹配需结合业务场景设计1. 分片键的选择原则分片键是分表的依据需满足高频查询字段选择业务中查询时必带的字段如订单表的user_id、order_time避免无分片键的跨分片查询基数适中避免基数过低如 “性别”会导致分片数据倾斜或过高如 “订单 ID” 需配合哈希 / 取模分散避免热点分片选择分布均匀的字段如用户 ID 取模防止某分片数据量过大成为性能瓶颈。2. 分片策略选择根据业务场景选择对应的分片策略分片策略适用场景示例取模分片哈希分片需数据均匀分布的场景如用户表、订单表按user_id % 10分 10 张表user_0~user_9范围分片按时间 / 数值范围查询的场景如日志表、月订单表按order_time分表order_202501、order_202502复合分片键多维度查询的场景按user_id % 8order_time先按用户分 8 片每片内按月份再分3. 分表粒度匹配业务若业务需高频查询 “某用户的所有订单”选择user_id作为分片键查询直接路由到对应分片若业务需高频查询 “某月份的订单统计”选择order_time作为分片键按月份分表。二、ShardingJDBC 的查询逻辑ShardingJDBC 的查询核心是根据分片键路由到目标分片路由逻辑分为三类直接路由查询条件包含分片键ShardingJDBC 通过分片策略计算出目标分片仅查询该分片性能最优。示例SELECT * FROM order WHERE user_id 123user_id是分片键直接路由到user_123%10分片。广播路由查询无分片键或需全分片操作ShardingJDBC 会向所有分片发送查询请求合并结果后返回性能较差。示例SELECT COUNT(*) FROM order需查询所有分片的订单数并求和。笛卡尔积路由跨分片关联查询如多表 join 且无分片键关联ShardingJDBC 会在所有分片间做笛卡尔积查询性能极差需避免。三、分表后的优化逻辑避免全分片扫描所有查询尽量携带分片键减少广播路由若需全量统计可通过定时任务预计算结果存入汇总表。优化分页查询ShardingJDBC 分页如LIMIT 10000, 10会查询所有分片的前 10010 条数据再合并排序取 10 条大分页性能极差。优化方案用分片键 游标替代大分页如WHERE user_id123 AND order_id 10000 LIMIT 10业务层限制最大分页页数如仅支持前 100 页。减少跨分片关联使用绑定表将关联表按相同分片键分表如order和order_item都按order_id分表ShardingJDBC 会将关联查询路由到同一分片避免跨分片 join尽量在业务层拆分为单表查询后聚合。结合读写分离配置 ShardingJDBC 的读写分离规则查询请求路由到从库减轻主库压力。索引与缓存优化每个分片表需在分片键上建立索引提升单分片查询效率热点数据如高频访问的用户订单存入 Redis 缓存减少数据库查询。四、新建分片表的注意事项表结构完全一致所有分片表的字段、类型、长度、索引、约束必须完全相同如user_0和user_1的user_id字段类型必须都是 BIGINT否则查询会因结构不匹配报错。分片键必建索引每个分片表需在分片键字段上建立索引如user_id否则单分片内的查询会全表扫描。表名符合分片规则表名需与 ShardingJDBC 的分片规则匹配如取模分表需命名为user_0、user_1范围分表需命名为order_202501避免路由失败。提前初始化分片表分表需提前创建如按用户 ID 分 10 张表需提前建user_0~user_9不能在运行时动态创建会导致路由失败。分布式主键避免冲突不能使用自增主键不同分片的自增 ID 会重复需用分布式主键生成策略如雪花算法ShardingJDBC 可配置内置的分布式主键生成器。元数据统一管理通过 ShardingSphere 的元数据中心如 ZooKeeper管理分片表的结构和分片规则避免多实例间元数据不一致。