昨天被一个粉丝问了一个问题，关于先更新DB，然后删redis缓存；还是先更新redis缓存，然后更新DB的问题他给我发了如下图片：行内容1问题如下：2A、当B请求查询的时候，发现缓存中没有数据，去请求DB；如果B请求有N个，DB是否能支撑N个请求连接，如果N为几千，一万，五万，十万，甚至百万，你还认为你的数据库可以安然无恙嘛？3B、查询接口返回数据时，应该返回缓存中的数据，还是返回DB中的数据情况一：返回缓存中的数据，那还有必要纠结先更新缓存还是先更新DB嘛？必然先更新缓存啊情况二：返回DB中的数据，那还需要缓存数据吗？多此一举？脱裤子放屁？4C、缓存中的数据哪来？方案一：提前预热，那么应该是...

1、为了使用技术栈而写业务，技术栈用的对不对先不说，但是技术栈用了不少，即使它的作用微乎其微2、项目套路：一大堆技术栈 + 抠脚趾的业务 + 吹牛逼 + 项目业务小众3、学完项目之后看着会很多东西，实际情况一问三不知4、抱着吹牛逼的心态，拜托，公司只是想招点实习生减税，招个工具人，不是来和你较真的，不要老想着拷打面试官，面试官如果认真起来，哭的只有应聘者5、职场不是打打杀杀，而是人情世故！有抱大腿的机会，赶快抱，即使不能转正，也可以少走很多弯路！说不定哪天扩招，主管就把你转正了#职场新人生存指南##面试常问题系列##牛客创作赏金赛##java#

简历上的技术栈一定要具有层次感，比如基础--数据库--NOSQL--框架--微服务--运维工具注释：408可以提现应届生的专业素养注释：大家在学习多线程的时候，JMM往往是大家忽略的内容，但是JMM的内容是至关重要的掌握计算机网络、数据结构、计算机操作系统、计算机组成原理Java基础：掌握Java基础、如集合框架、Stream流、反射机制、网络IO、多线程、JMM、JUC并发编程JVM：熟悉JVM的内存模型、类加载机制、垃圾回收机制等MySQL：熟悉日志、MVCC、事务、索引、锁机制，具备慢SQL的优化经验NoSQL：熟悉Redis的基本数据结构、网络模型、持久化策略、分布式锁、高可用等机制框架：MyBatis、SpringBoot等，掌握IOC、AOP、自动装配机制、约定大于配置等特性微服务：熟练使用SpringCloud、SpringCloudAlibaba中间件：熟练使用Rabbit-MQ，如保证消息不丢失、重复消费、死信队列等特性运维工具：Git、Maven、Linux常用命令、ELK、Prometheus、Grafana注释：ELK可以当做日志排查工具，定位问题#java#注释：Prometheus + Grafana可以采集服务运行日志，为服务优化提供参考数据#简历#

需求背景： 1、商家可以在平台开通商铺，售卖商品【项目源码】 2、商品【项目源码】售卖期间，商家可以更新商品信息 3、用户可以在平台购买商品【项目源码】，生成相关订单 4、用户可以通过订单，每日最多下载三次 需求分析 1、用户购买成功后，下载的源码是商品最新的信息，还是购买时的信息 2、用户购买成功后，商家删除了商品部分信息，如何保证用户可以完整下载成功 功能设计 1、商品每次更新都成为一个新的商品，旧的商品状态改变 2、用户对旧的商品只能通过订单查看，不再支持购买 为什么这么设计？ 1、不需要维护用户订单和商品文件的关联性 2、缩小商品信息更新产生的影响范围，遵循开闭原则

在实际工作中，项目的API层，Service层，Model层，Mapper层是怎么划分的？项目的文件目录划分取决于项目本身的业务功能，如果业务功能单一，采用我们常用的层次机制，就可以满足开发需求；但是在工作中，业务功能往往是比较繁琐复杂的，如图1、业务涉及到的通用的SDK业务可能会涉及到通过其他项目获取数据，或者充当Feigh层满足不同组件之间的接口调用当涉及到其他项目的数据时，我们往往不能直接获取数据，其他项目也不会因为我们的业务为我们提供一些定制接口，此时就需要通过SDK来满足业务对数据的需求2、common组件用于存放项目涉及到的基础Model，通用枚举，通用异常，通用常量，通用工具类等...

本地缓存是指在服务节点中的缓存，也就是说会占用JVM的内存那么这种情况会造成哪些问题呢？1、JVM可能会频繁GC2、服务节点可能会出现卡顿3、本地缓存难以维护4、数据一致性问题#实习工作，你找得还顺利吗？#

数据闭环：当一个数据/资源产生后，在经过某个业务逻辑后会被消费掉，如果没有被消费，就会造成资源浪费同理，JVM中叫做内存泄漏，redis中叫做内存溢出【大家可能会说redis会有自身的淘汰策略，但这个并不是重点，因为淘汰策略可能会造成资源丢失】-------------------------------------------------------------------------------------------针对键的策略设置过期时间：有效期后自动删除键值，有效期可以根据使用情况刷新不设置过期时间：当需要使用数据时，加载到内存中，当不需要使用数据时，从redis中删除-------...

首先针对数据库表的操作分为增删改查，但实际只有改查【读写】，因为增加和删除都是修改类型，那么大方针就可以确定了关于写【增加/删除/修改】1、我们需要保证表中的数据相对有序，这里就需要考虑雪花算法了，可以保证主键ID的相对递增--------------------------------------------------------------------------------------------主键ID相对递增的优势： 1、保证IO顺序操作，顺序IO比随机IO性能高 2、减少页分裂和页合并 3、减少不必要的额外排序，避免产生额外排序内存使用，比如按照添加时间排序 4、针对范围...

简历上的技术栈一定要具有层次感，比如基础--数据库--NOSQL--框架--微服务--运维工具 注释：408可以提现应届生的专业素养 注释：大家在学习多线程的时候，JMM往往是大家忽略的内容，但是JMM的内容是至关重要的 掌握计算机网络、数据结构、计算机操作系统、计算机组成原理 Java基础：掌握Java基础、如集合框架、Stream流、反射机制、网络IO、多线程、JMM、JUC并发编程 JVM：熟悉JVM的内存模型、类加载机制、垃圾回收机制等 MySQL：熟悉日志、MVCC、事务、索引、锁机制，具备慢SQL的优化经验 NoSQL：熟悉Redis的基本数据结构、网络模型、持久化策略、分布式锁、...

限流维度限流维度时间限流：基于某段时间范围或者某个时间点，针对时间窗口做限流资源限流：基于可用资源的限制，比如设定最大访问次数/最高可用连接数限流角度QPS和连接数控制：1、IP维度限流2、单个服务器的限流3、多维度限流规则：比如设定同一个IP每秒访问频率小于10，连接数小于5，再设定每台机器QPS最高为1000，连接数保持200；或者将某个服务器组或者整个机房的服务器当做一个整体进行流量控制传输速率：背景：资源的下载速度限流方案：普通用户和会员用户的速度进行区分黑白名单：黑白名单是各个大型企业应用里常见的限流手段，黑白名单一般是动态调整的；如果某个IP在一段时间的访问次数过于频繁，被系统识别...

首先抛砖引玉，了解一下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、如何处理宕机的服务：服务下线 服务注册作用：获取服务节点的身份信息，服务名称方案一【由注册中心主动访问网络节点的所有机器】模型复杂：对于跨局域网的分布式...