首先抛砖引玉，了解一下InnoDB缓冲池的脏页：当缓冲池数据页上的数据发生变化后，就变成了脏页，此时脏页还没有更新到磁盘上，但是它同样可用；同比，redis==InnoDB缓冲池的数据页， DB==InnoDB的磁盘脏页如何刷新到磁盘上呢？有很多种策略，都可以保证脏页刷新到磁盘上；最明显的策略就是通过后台线程刷新到磁盘上同比，redis的数据发生变化后，也可以设计一个后台服务来保证redis的脏数据更新到DB当用户流量到达一定级别的时候，系统结构和运行机制必然会进行迭代升级，任何一个请求都可能不再是从请求到DB再返回给用户的一个机制了；我们需要保证系统的稳定性，因此作出以下调整：1、用户的请...

首先对操作的价值进行定义：操作积分值评论4点赞3收藏2浏览1对用户/文章的积分表进行设计字段类型描述idvarchar唯一IDuser_id / essay_idvarchar用户ID/文章IDscore_totallong积分总值lately_hour_scorelong最近一个小时获取的积分last_hour_timedatetime上一个小时的时间active_scorelong活跃值 = score_total * 0.3 + lately_hour_score * 0.7create_timedatetime记录创建时间update_timedatetime记录更新时间业务流程

不可重复读多次查询，获取到的数据值不一致幻读多次查询，获取到的数据条数不一致注释：同时对当前读做一个讲解首先，我们创建一个表 CREATE TABLE `book` ( `id` int NOT NULL AUTO_INCREMENT, `name` varchar(20) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 接下来，我们可以插入两条数据 insert into `book` (`id`, `name`) values('1','第一本书'); insert into `book...

名称 区别 行锁 不适合在高并发场景中出现，如果行锁的数据行是一个商品的库存，那么当行锁被某个请求占有后，所有的请求都需要等待行锁的释放，那么所有的请求都变成了排队执行/随机执行 本地锁 本地锁的适用范围是当前服务，同样的服务部署在不同的节点中的锁没有关联，同样不适用高并发场景 分布式锁 分布式锁的适用范围是所有的服务节点/分布式场景 高并发场景的原则：尽量避免锁的出现，不管是秒杀场景/超卖场景，都应该避免锁的出现，为什么要这么规划呢？ 1、我们需要考虑所有用户的请求可以并发执行，同时不被干扰 2、在高并发场景中，如果存在锁，必然会出现大量的创建和销毁影响系统的性能 3、...

Eureka服务治理服务治理的优点a、高可用性：保证服务的可用性b、分布式调用：服务治理框架需要具备在复杂的网络环境中准确获知服务节点网络地址的能力；服务消费者可以借助服务治理框架的能力，准确向服务节点发起请求c、生命周期管理d、健康度检查：根据服务状态，及时剔除下线服务 服务治理需要解决的问题a、如何获取服务提供者的信息：服务注册b、如何从服务治理框架找到服务提供者的地址：服务发现c、如何感知服务提供者的状态：心跳检测，服务续约，服务剔除d、如何处理宕机的服务：服务下线 服务注册作用：获取服务节点的身份信息，服务名称方案一【由注册中心主动访问网络节点的所有机器】模型复杂：对于跨局域网的分布式...

最近看了很多简历，做一个问题汇总：1、使用 CompletableFuture 优化首页査询模块，对文章列表、侧边栏、分类信息由串行调用改造为并行加载，响应时间从 1s 降低至 0.2s 疑问：每个内容板块都有一个接口返回内容快，还是一个接口返回所有的内容快？ 2、采用自旋锁策略优化缓存架构，针对热 key 的并发访问进行同步，防止其失效时导致的缓存击穿 注释：我在网上找了一下自旋锁策略优化的案例 public class SpinLock { // 使用原子引用来避免可见性问题和竞态条件 private AtomicReference<Thread> owner ...

假如我们可以打开上帝视角，每次重试，我们都知道再多一次/n次重试就可以成功，那么我们的重试次数应该加多少呢？假设有一个大量用户操作的场景，必然会面临大量重试，那么下游是否允许出现这么多次调用失败呢？大量的调用失败是否会造成灾难传递呢？接下来，我们引入服务雪崩和服务降级，以及服务熔断的机制，再来解析一下这个场景同样，每个场景我们都打开上帝视角，假设我们重试到第n次一定会成功，那么进行n次重试会对我们的系统造成什么影响？1、用户请求刚进入系统后，假设需要获取一个公共的分布式锁此时意味着有更多的用户同时进行重试造成锁竞争更激烈，同样大量的用户重试也会造成大量的压栈操作，对JVM的内存造成冲击2、主链...

项目讲解一系统架构：以 SpringCloud 微服务架构，将系统拆为推单服务和配单服务 核心技术：SpringBoot、Mybatis、Redis、Nginx、Kafka、MySQL 项目描述： 由于公司业务扩展，需要对接话费充值代理商，于是开发一套话费充值系统来扩展公司业务。这是套中后台系统的ToB类型的项目，该系统由推单系统和配单系统组成，推单系统用来对接话费订单渠道商，配单系统对接运营商。 【1、话费订单渠道商都做了什么？；2、运营商都做了什么？】话费业务的特殊性，月初月末都会有较大单量在 15 万左右，TPS 峰值是在 700 左右，QPS 峰值在 1500 左右。 【一天产生 3w...

#我的失利项目复盘##java##java面试题##java项目##项目#在给别人做模拟面试时，看到的项目某某商城某某商城为某某APP 首页核心业务之一，用户通过首页可直接接入到商城进行浏览、购物行为。商城团队历经了历次大促、活动促销的考验，我司作为合作方与某某大厂架构团队一起完成商城平台的开发建设；我作为核心开发人员参与了商城商品中台建设、库存中心、微服务改造升级、子系统接入、分库分表、拼团营销、金币抽签、合并支付等业务与架构工作。·技术难点：库存中心·技术挑战：商城经常做促销活动、秒杀场景, 商品瞬时进行库存扣减造成 redis 机器流量倾斜问题。 【秒杀场景需不需要单独的服务器，秒杀场景是否需要加锁；促销活动中，活动资源如何评定；】·技术方案：实现了一个高性能，可支撑分桶多分片的库存中心，提供单库存分片不足扣减的合并库存功能，提供商品操作库存入库的渐进性入缓存的实现。【如何保证数据的一致性；分桶多分片的库存扣减完整业务/时序图】·技术难点：数据迁移平台·技术挑战：分库分表方案敲定，为了实现数据迁移、数据同步需要完善可靠的数据迁移系统【数据量有多大？分库分表后，如何保证数据闭环，业务是否需要修改】·技术方案：研发数据迁移系统，包括了业务表（订单、订单详情等）,迁移表、迁移配置表等。实现了全量同步滚动拉取、增量同步（基于 Cancal+MQ）防止数据丢失和高效写入方案。实现了单库到八库八表的实践。 【binlog和redolog的区别，binlog异步迁移是否存在风险，是否会造成查询过程卡顿】社交分享平台 【刚培训结束，自己做的面试项目】项目介绍 ：社交分享电商平台旨在为用户提供分享购物心得，并可以直接购买相关商品。该项目分为管理端和用户端。用户端核心业务有：查看附近门店、发布笔记（获取积分）、签到、点赞和收藏，以此带动用户的活跃度。还可以发放一些优惠券，促进用户消费。管理端核心业务有：用户的笔记、评论、商品、优惠券的管理。 使用技术 SpringBoot、SpringCloud、RabbitMQ、Redis、XXL-JOB、Redisson、Mybatis-plus、分库分表等。 【接口性能主要在哪些地方消耗较大：IO】工作职责 1、采用百度地址编码和路线规划服务，为用户和商家地址提供查找附近门店的功能。 2、采用Redis位图 ，优化用户签到功能，减少内存消耗。 【按照每周讲解一下位图怎么使用：0000000---》0000001---->0000011】3、采用Redis SortedSet数据结构存储用户本月积分排行，使用MySQL分表存储历史积分排行。 【积分排行持久化的作用】4、采用XXL-JOB实现分布式任务调度，定时持久化上赛季积分排行，根据当月和历史积分排行发送优惠券。 【历史数据较多时，如何进行数据对比？】5、开发可扩展和通用的点赞/踩模块，利用Redis Set数据结构存储用户点赞明细， SortedSet数据结构存储特定业务项的点赞总数，增加用户互动性。 【为什么要用有序集合存储点赞明细】6、采用RabbitMQ实现消息队列，将点赞总数放入消息队列，实现系统解耦和异步处理， 提升系统响应速度。【点赞总数在什么场景下会被持久化DB层；场景如何界定】 7、设计支持多类型配置的优惠券系统，采用策略模式选择不同类型的优惠券。 8、解决了超发和超领问题。使用JMeter工具进行压测，确保并发安全和提高用户体验和平台性能。 9、采用乐观锁思想解决优惠券超发问题，利用关系型数据库写锁排他性保证并发安全。 【如何不使用锁解决超发问题？】10、采用Redisson分布式锁解决优惠券超领问题，结合SPEL表达式、工厂模式、策略模式和AOP思想，封装自定义分布式锁注解。个人成就 1、查询点赞状态使用 ，从单命令执行，改为RedisTemplate 的 executePipelined 方法进行批量处理，优化系统响应时间（ 40s->100ms）。 2、多线程优化大批量数据插入速度：由于cdk的生成需要将这批码插入数据库中保存，当创建十万条cdk记录时，耗时达到了十几秒。使用@Async+自定义线程池的方式，异步生成cdk，优化后执行耗时2.5秒，执行时间缩短了6倍。 【批量插入的数据是否会受到间隙锁的影响；数据在插入过程中，如何避免/减少页分裂/页合并的产生/受到间隙锁的影响】3 、基于Redis异步领券响应速度：在兌换资格校验的时候，或者领券资格校验的时候，会有多次与Redis的交互，每一次交互都需要发起一次网络请求。在并发较高的情况下导致网络拥堵，导致业务变慢。通过编写LUA脚本，在脚本中编写复杂业务判断，通过一次请求，完成对脚本的调用。提高接口响应速度。

最近在牛客上看到大量的Java简历，发现大家的简历多多少少会有一些很明显的问题如果感觉自己的简历有瑕疵，可以来找我，不做简历优化，也不做模拟面试，只修改简历上明显的问题【免费的】#简历##简历被挂麻了，求建议# #java##八股文#

场景题会根据大家遇到的问题，持续更新#java##秋招##实习##23届找工作求助阵地##八股文#专栏地址：https://www.nowcoder.com/creation/manager/columnDetail/mPZY5M

Java简历项目亮点是优势，也是被坑最惨的地方由于市面上大部分资料都讲解的一知半解，导致应聘者在面试过程中直接无从下手注释：任何方案都有对应的场景，我们要尽可能的保证我们的方案适合大部分的场景亮点一：秒杀场景1、被争抢的资源是什么？2、用户下单后，不进行支付，被争抢的资源是否会被扣减？3、超时未支付的订单释放后，资源是否会回归被秒杀的资源池中？4、如何不使用锁，实现秒杀场景？5、如何保证所有用户公平的争抢资源，而不是限流排队等机制亮点二：缓存DB一致性问题1、策略一：布隆过滤器【大家简历上经常使用的一种方案】2、策略二：先写DB后删缓存/先删缓存，后写DB【两者都是有问题的】3、策略三：本地缓存【本地缓存必然会造成更复杂的IO通信，一方面我们要维护本地缓存不会丢失，另一方面需要与缓存层/DB层保证数据的一致性】亮点三：消息异步处理1、如何保证消息处理的绝对顺序2、如何避免消息重复消费【消息重复消费是可怕的，博主就曾在线上遇到过消息重复消费，造成了发布事故】3、如何避免消息堆积/丢失等问题#java##秋招##简历中的项目经历要怎么写##项目#  秒杀场景要不要加分布式锁？--第一版-牛客网 https://www.nowcoder.com/issue/tutorial?zhuanlanId=mPZY5M&uuid=b34217fc53ab4aaca52c6fd65bae548f

秒杀场景缓存一致性问题消息异步处理主链路异步处理定时任务大数据量处理其他请牛友们补充#java项目##简历##秋招#  Java已读不回？_牛客网 https://www.nowcoder.com/feed/main/detail/bfb310e6f6a24f048110d3cda04e4651?

背景：高并发一百万条数据的订单没支付，如何快速超时和回滚预扣除库存设计思路：重点不在于数据量的多少，在于失效库存重新变成有效的库存，并且不影响正常库存的操作，那么就需要进行解耦，大家各玩各的，通过后台服务进行数据的交接就可以了；大数据量的处理过程从来都不是一个事务/多个事务就可以处理完成的，我们需要先注重服务的稳定性，而不是数据量的大小，数据量的处理速度取决于消费者的能力，但是我们首先要保证我们正常功能的稳定性，以及数据变态变更的平稳过渡总结：他打他的总攻，我玩我的游击后台服务参考InnoDB后台线程机制，商品回收【充当脏数据】和正常商品完全解耦

1、接口优化的依据 通过Prometheus+Grafana工作之后，我们每天早上都要通过监控图表观察自己负责的组件1、统计接口调用时长和平均时长：如果调用时长远超于平均时长，需要排查是服务器的问题，还是SQL的问题导致接口完成时间加长，是否需要添加缓存增加执行效率，是否需要索引优化2、统计接口调用次数：针对经常被调用接口的所在组件，进行节点数量的调整/索引优化/增加缓存3、统计用户操作次数和常用功能：可以更精准的对接用户群体和需求4、统计服务的异常信息：4.1、针对未知异常：需要在下此次迭代中进行改进4.2、针对已知异常：如果是操作不正确，需要加大用户操作软件的培训；如果是用户资源不足，需要...