meituan2

缓存

将缓存推到离用户最近的地方。

脏缓存清理

多级缓存

redis缓存

热点内存本地缓存

nginx proxy cache缓存

nginx lua缓存

redis缓存

可以配置刷新磁盘策略？

redis是集中式缓存节点：redis缓存管理方便

怎么均匀分散？

redis部署方式

单机版：故障单点瓶颈、挂了业务都会block。
哨兵模式: sentinal 心跳检测选master
- 缺点：多套主从的时候，新增一个机器，hash值计算要在客户端重新计算，机器还涉及到数据迁移。
集群cluster模式：雪花状集群，两读两写，每台机器都和其他机器网状连接，我在集群中处于什么地位。有竞争算法。
- 超过半数投票，就可以认为这个状态。
- 使用时连接任意机器，就可以查询所有数据。
- 当某一个故障，rehash分片会进行调整。对应key不在自己机器管理范畴，reask返回给客户端。
- jedis jar包，已经集成了这种管理。
- jedis客户端已经集成了这个配置。

redis部署集群方式通信

redis的数据格式能存哪几种编码方式 bitmap怎么存全栈的签到三天次数

交易的逻辑相关面试问题

dubbo

Dubbo本身是有监控的【Monitor】，provider和consumer都会将一些统计信息进行监控。
Dubbo的注册中心最常见的是Zookeeper和Redis这些常见的分布式中间件，同时Dubbo也支持自定义扩展中心和多注册中心的配置。
Dubbo协议特点：传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要用dubbo协议传输大文件或超大字符串，基于以上描述，我们一般建议Dubbo用于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。
Dubbo是把微服务之间的调用发挥到了极致，除了速度还提供了很多诸如本地存根，隐式参数之类的特性。但是SpringCloud更偏大而全，提供了微服务的整套服务治理的方案。

dubbo特性

启动检查
- 检验服务提供者的可用性。验证过程中出现问题，阻止整个Spring容器初始化。
- 不建议取消这个检查。@Reference（interfaceClass = UserAPI.class, check = false）
- 一般谁引用，就在谁里面配。
负载均衡
- Random 随机
- RoundRobin 轮询（常用）
- LeastActive 最少活跃调用数。使慢的提供者收到更少的请求。（常用）
- ConsistentHash 一致性hash 相同参数的请求总是发到同一提供者。（不常用）
多协议支持 protocol
- name：dubbo （常见的）
- 还支持RMI、Hessian、HTTP、Redis等
- 这些主要差异在连接方式上
  - dubbo 长连接、单连接，TCP协议，NIO异步传输。100K左右极限。
异步调用
- NIO 非阻塞
- Future特性
  - 调用过去返回一个Future 5.等待结果
  - 不用阻塞
热点数据缓存结果缓存
- dubbo 类似osCache 本地缓存
连接和并发数控制
- 超出部分以错误形式返回
- 可以防止服务雪崩
dubbo服务分组
- 一个接口有多种实现

数据库 binlog 能存几种格式什么时间存的

性能

性能评估指标

并发
TPS 每秒处理的transaction （数据库中是写入的）
QPS 一秒钟处理多少查询（数据库中是查询快照读）
耗时端到端耗时服务端耗时
95线 95%的请求落在什么范围 eg：250ms 去掉网络抖动的影响
99线

GC

分代收集算法

年轻代
老年代
- 啊
1.8及之前用CMS 好一点 1.8之后用G1

CMS 和 parnew

https://www.cnblogs.com/jiangym/p/15885161.html#_label4_0

并发的时候不STW，单个的时候一般都STW
初始标记标记根的可达性
并发标记遍历标记根下面的可达性
重新标记标记并发期间的可达性

GC调优一般要把STW时间缩短。

最大收集时间例如50ms
比cms 寻址递归效率高，G1有单元和内存对象分配和标记，空间换时间

调参

内存大小取舍

扩大内存可更少触发gc
内存太大，触发gc停顿的时间长

参数

吞吐量非GC停顿/总时间至少优化到95%
Xms 启动时堆内存大小
Xmx 堆内存最大限制一般设置成一样防止扩缩容
-XX:NewSize 年轻代大小 -XX:MaxNewSize 年轻代大小一般也都设置成一样

优化参数

yongGc 40ms内

major gc stw总和100ms内

fullgc 1s内

CMS

cms要设置线程数因为程序默认读的是机器的不是docker的，设置了才能读需要的数量。

3,4：触发两次fullGC才去碎片整理

70是fullGC阈值

5：设置only ，就是每次都用这个阈值。

G1

日志

同步日志
- log.info 直接同步刷盘高并发打info 对磁盘有压力内容大。刷盘阻塞。
- 所以一定要有效，只打关键信息。
异步日志
- log4j的synclogger 异步刷盘。有一个内存管道buffer，有可能失败，打印不出来。
日志归档
- error.log -> error_2000_1_1.log
- 这个过程是error.log加锁了, 之后打zip包，清空error.log，再新建error.log。
- 在这个期间，写入都阻塞。
- 可以改成大小切分，打包快，而且分散。
- 切分阈值要有控制。
- 要0点左右随机秒级时间偏移归，防止量大。
- 切分之后，trace影响。