xzh_blog

IntObjectHashMap没有和JDK的HashMap一样，使用链表法来解决hash冲突，而是使用了线性探测策略的开放寻址法，由于使用开放寻址，在hash碰撞较为严重的场合，其查询性能比HashMap会更好，但是其扩缩容的代价会比HashMap更大，性能更糟。IntObjectHashMap的value就是真实的value，不像HashMap内部维护的Node，也会更节约内存。以及其他包下的集合，org.antlr.v4.runtime.misc.IntSet 也可以压缩数据。经测算，存入1万数据，

Session一般译作会话，用户访问web应用时，服务端会给每一个用户（浏览器）创建一个Session对象。缺点：每次http请求都携带Session占外网带宽，Session存储的数据大小受Cookie限制。缺点：Session同步需要占用内网带宽，如果服务比较多性能直线下降，也无法水平扩展。方案三 服务端同步Session，使用Tomcat同步复制保存Session。缺点：服务端重启后Session丢失，服务端水平扩展需要rehash。缺点：需要修改服务端代码。

技术架构图

@Target(ElementType.METHOD)@Retention(RetentionPolicy.RUNTIME)@Documentedpublic @interface Limiter { /** * 限制时间（秒） * * @return */ long limitTime() default 2L; /** * 限制后的返回内容 * * @return */ String

原子操作单库修改，几乎无锁竞争，性能好，但性能有上限，可能数据库单点故障。拆分key可以将数据量比较大的key-value，拆分为多个key-value，分拆单次操作的压力，将操作压力平摊到多个redis实例中，降低对单个redis的IO影响。令牌队列类似于令牌限流，将对库存的竞争转换为对令牌的竞争，拿到令牌才可拿库存。自旋互斥超时锁可以对多线程进行互斥，实现同个类型的数据只有一个线程在运行。CAS乐观锁无锁竞争的原子操作，事务执行期间相关的缓存没有修改才会提交成功。Redis

定时轮询、惰性取消、JDK延迟队列、时间轮、Redis过期回调、Redis有序集合、任务调度、消息队列

缓存通常使用key-value的map数据结构来实现，并发读写缓存时可能会出现数据不一致问题，此时就需要引入读写锁。当吞吐量很高时（每秒20w写，1k读），锁会成为潜在瓶颈，导致Map访问效率极低。这时可以将map水平拆分（类似于数据库里的分库，把一个库锁变成多个库锁，来提高并发，降低锁冲突。）key%n → 多个map。极致做法是map → array，一条数据一把锁，但这样内存装不下。...

调用第三方API可能存在的问题：公网抖动，第三方服务不稳定，影响自身服务；一个接口超时，占住工作线程，影响其他接口；

技术选型、接入层架构、急速性能优化、微服务架构、数据库架构、缓存架构、架构解耦、架构分层、架构进阶

高并发，几乎是每个程序员都想拥有的经验。原因很简单：随着流量变大，会遇到各种各样的技术问题，比如接口响应超时、CPU load升高、GC频繁、死锁、大数据量存储等等，这些问题能推动我们在技术深度上不断精进。在过往的面试中，如果候选人做过高并发的项目，我通常会让对方谈谈对于高并发的理解，但是能系统性地回答好此问题的人并不多，大概分成这样几类：1、**对数据化的指标没有概念**：不清楚选择什么样的指标来衡量高并发系统？分不清并发量和QPS，甚至不知道自己系统的总用户量、活跃用户量，平峰和高峰时的QPS和TPS等

牛B的人物，早已经厌倦了中英文混杂，他们更进一步，使用中英文缩写，对普通人进行降维打击。更厉害的，造就新的名词，并科普出去。有几项技术，我从心底里鄙视和厌恶，但每次在技术方案中，都默默的把它们加进去，而且给足了它们分量。因为它们对于方案的成功与否，起着重要的概念性指导作用。它们就是中台、低代码，以及DDD。这三个不同领域中的技术，肩负着同样的责任，那就是往死里忽悠。这三个词，很伟大，它们有一个共同点，都是很容易说服非技术但能决策的人员，然后向下铺开，非常具有营销型，是职业经理人和CTO的最爱。也是咨

Redis的使用非常简单，只需要安装配置一下就能轻松上线，短时间不会出现什么问题，但是随着时间推移，Redis实例增多，客户端调用繁杂，真正的问题开始出现，整个关系就变得非常乱。Redis从使用角度来讲是需要像应用服务一样去治理的。下面先看一段日常开发过程中常见的对话：开发：Redis为啥不能访问了?运维：刚刚服务器内存坏了，服务器自动重启了。开发：为什么Redis延迟这么久?运维：大哥，不要在Zset里面放几万条数据，插入排序的后果很严重啊!开发：写进去的key呢，为什么不见了?运

在做分析或思考总结时，一般采用结构化思维方法:·首先梳理目标，理清目标与现在或将来发展的关系。其次做现状分析，知道有什么、缺什么、现状与目标的差距，以及眼下首要的任务是什么。接下来是路线与措施分析，并制定可以保证有效执行的方案。最后是下定决心以较高的执行力来实践。...

SRP：单一职责原则容易误认为是指：一个软件模块都应该只做一件事，实际上并不准确。单一职责原则准确描述应该是：一个软件模块都应该只对一类行为负责。如果多个特性不同的项目同时依赖同一个底层接口，只要有任意一个项目需要改动依赖的底层接口逻辑，就会影响到其他项目。单一职责原则主要讨论函数和类之间的关系，但在两个层面上有不同的表现形式。在组件层面，称为共同闭包原则；在软件架构层面，则用于奠定架构边界的变更轴心。OCP：开闭原则良好的软件设计应该是易于扩展，抗拒修改。开闭原则主要目的是让.

最好不要出现跨库join，应该在设计的时候就避免。将需要join的表放在同一数据库，即便是分库分表看能不能按相同维度分到一起。或者看能不能设冗余字段，避免关联查询。那如果无法避免跨库join，也应该走微服务API查询，或者使用中间件实现。一定要跨库join，MySQL也是可以支持的：1.开启FEDERATED引擎，修改my.ini（或my.cnf）文件新添加一行，内容为federated，然后重启MySQL。2.在数据库中建立远程表，通过参数CONNECTION='mysql..

负载均衡算法可以分为两类：静态负载均衡算法和动态负载均衡算法，另外还可以自定义负载均衡算法。静态负载均衡算法轮询（Round Robin）：服务器按照顺序循环接受请求。 随机（Random）：随机选择一台服务器接受请求。 比率（Ratio）：给每个服务器分配一个权重值，根据权重分配请求。 Hash（Hash）:根据客户端IP的hash值取模访问对应服务器。 一致性Hash（Consistent Hash ）：相同IP的客户端请求总是发送到同一服务器。动态负载均衡算法最少连接数（Leas

什么是双写同一份数据，需要写数据库、写缓存。双写很难保证强一致性，可以保证最终一致性。要做到强一致性就需要将所有读写请求用队列串行化，但是性能非常差，降低系统的QPS。没有完美的方案，用到缓存就会存在不一致的情况，需要根据具体业务权衡得失，选择合适业务的方案。先更新数据库，再删除缓存（推荐方案）此方案数据不一致的几率比较低，并且实现简单。造成数据不一致的情况：在缓存刚好失效时，有线程查询数据库得到旧值，另外一个线程更新数据库并删除缓存后，前面持有旧值的线程将数据存入缓存，造成数据

一致性哈希目的是解决哈希算法动态伸缩的问题，使得在进行扩容时尽量少的进行数据同步。一致性哈希算法将整个哈希值空间映射成一个虚拟的圆环，整个哈希空间的取值范围为0~2^32-1。整个空间按顺时针方向组织。0~2^32-1在零点中方向重合。接下来使用如下算法对服务请求进行映射，将服务请求使用哈希算法算出对应的hash值，然后根据hash值的位置沿圆环顺时针查找，第一台遇到的服务器就是所对应的处理请求服务器。当增加一台新的服务器，受影响的数据仅仅是新添加的服务器到其环空间中前一台的服务器（也就是顺着逆时针方向

系统的高可用需要考虑到：自身服务的高可用、上游与下游服务的影响。自身服务需要做到监控、压测、降级、拒绝服务、弹性伸缩，控制资源合理的使用，如：CPU、内存、磁盘、网络、线程，一旦某个资源超过负载，很容易出现线上问题。进行服务冗余，异地容灾、集群部署、负载均衡。对上游服务做好监控、限流，对下游服务做好重试、熔断降级、兜底方案。还有数据存储高可用，数据主从复制、数据主从切换、数据分片(分库分表)。参考：如何保障高并发系统的稳定性与高可用全面！一文理解微服务高可用的常用手段 ...

百度百科定义：如果观看抽奖或秒杀系统的请求监控曲线，你就会发现这类系统在活动开放的时间段内会出现一个波峰，而在活动未开放时，系统的请求量、机器负载一般都是比较平稳的。为了节省机器资源，我们不可能时时都提供最大化的资源能力来支持短时间的高峰请求。所以需要使用一些技术手段，来削弱瞬时的请求高峰，让系统吞吐量在高峰请求下保持可控。流量削峰方案：无损方案：排队、验证、分层过滤，不会损失用户发出的请求。有损方案：限流、熔断，会损失用户发出的请求。排队用消息队列来缓冲瞬时流量，把同步的直接调用转

热点数据发现1.发现静态热点数据：静态热点数据的发现相对简单些，是可以提前预估预测的数据。比如：秒杀活动商品、降价促销商品、节假日的火车票机票、热门电影门票、明星发布新专辑，以及大数据分析流行趋势预测热点。2.发现动态热点数据：创建异步监控统计服务和热点数据服务。异步监控统计服务在一个周期内对Key进行请求统计，在达到请求量级后将热点Key发送到热点数据服务收集，然后热点数据服务对这些热点Key进行聚合分析，最后推送到业务系统。热点数据处理1.缓存热点数据，放入LRU队列淘汰替换。.

这里同时存在三个问题：1.问题排查以及快速恢复2.异常数据修复3.服务高可用，规避服务宕机先抢通业务　　当发现服务器宕机后，最关键的是抢通业务，而不是抢修服务器。因此，需要做应急方案。最好准备2个网站服务器，他们存放的内容相同，而ip不同，并且机房的地理位置不同。这样第一时间发现宕机问题后，可以迅速的通过修域名记录，指向目前正常的网站空间。而且2个主机，同时宕机的可能性就大大降低了。服务器崩溃问题定位1.内存溢出，磁盘资源耗尽2.线程死锁，进程过多或者不断创建，耗尽资源..

1.数据库主键或唯一索引。2.数据库乐观锁。3.数据库字段状态。4.数据库防重表（流水表）。5.redis令牌，先获取唯一key，再请求业务系统，查找并删除key。6.下游服务唯一序列号，请求时在redis存个有效期的key，若存在就说明执行过。7.分布式锁。8.全局唯一号。source(来源)+seq(序列号)，多个三方系统采用此方式。详细：https://mp.weixin.qq.com/s/7AZDaF4m8yGe19yNb_V7cAhttps://www.

分布式锁的实现，目前比较常用的有以下几种方案：基于数据库实现分布式锁； 基于缓存（Redis，memcached）实现分布式锁； 基于Zookeeper实现分布式锁。分布式锁的要求：可以保证在分布式部署的应用集群中，同一个方法在同一时间只能被一台机器上的一个线程执行。 具备锁失效机制，防止死锁； 具备非阻塞锁特性，即没有获取到锁将直接返回获取锁失败； 高可用的获取锁和释放锁功...

No.1：重复代码的提炼 重复代码是重构收效最大的手法之一，进行这项重构的原因不需要多说。它有很多很明显的好处，比如总代码量大大减少，维护方便，代码条理更加清晰易读。 它的重点就在于寻找代码当中完成某项子功能的重复代码，找到以后请毫不犹豫将它移动到合适的方法当中，并存放在合适的类当中。class BadExample { public...