设计分布式锁要注意的问题

分布式锁应该具备的条件:

1、在分布式系统环境下,一个方法在同一时间只能被一个机器的一个线程执行;
2、高可用的获取锁与释放锁;
3、高性能的获取锁与释放锁;
4、具备可重入特性;
5、具备锁失效机制,防止死锁;
6、具备非阻塞锁特性,即没有获取到锁将直接返回获取锁失败。

实现方式(方案):
1、基于数据库(mysql,sqlserver等)
2、基于redis
3、基于zookeeper

方案比较:

1、从理解的难易程度角度(从低到高)
数据库 > 缓存 > Zookeeper
2、从实现的复杂性角度(从低到高)
Zookeeper >= 缓存 > 数据库
3、从性能角度(从高到低)
缓存 > Zookeeper >= 数据库
4、从可靠性角度(从高到低)
Zookeeper > 缓存 > 数据库

面试问题整理

技术类:
1、redis如何水平扩展(一致性哈希)
2、parallelStream使用中的问题(线程安全,聚合与否,共享线程池问题)
3、dubbo的实现原理,调用过程,dubbo异步调用实现
4、future原理
5、jvm加载过程(校验,加载,空间分配,静态变量,静态方法等)
6、双亲委派机制
7、线程池常用核心参数,以及设置原因(IO密集型线程,CPU密集型线程)
8、redis为什么单线程,如何保证效率的(单线程只是用来连接)
9、redis的一些命令
10、redis的数据类型
11、jstack,jmap等线上排查问题工具,用法
12、Linux常用命令 (z)grep ,cat ,sed ,awk ,wc(统计),去重等
13、如何查看异常挂掉的进程日志
14、数据库事务 隔离级别,默认隔离级别,实现原理(mvvp)
15、数据库索引 主键索引,单列索引,组合索引,唯一索引(聚簇索引),覆盖索引;全文索引(非聚簇索引);命中逻辑,结构(B+树,适合区间查询,只在叶子节点存有数据,单节点能存更多数据,减少IO)
16、锁:乐观锁,悲观锁,各种锁,以及不同应用(如JAVA,MySQL)中的实现喝可用库
17、数组下标,为什么从0开始?数组的地址真的是连续的嘛?数组在栈还是堆上?(栈,jvm内存模型)多个进程共享的时候,如何保证数组在内存中的地址是连续的?
18、hashmap的推演及变形问题
19、spring 事务(@Transanctional)的实现原理
20、mysql事务索引,mysql非唯一索引条件下update的加锁问题
21、redis高并发多操作实现事务方案(lua脚本)

方案类:
1、分布式锁
2、幂等(最终一致性)
3、128位数字加减问题(数据结构如何设计,用什么基础类型,位数是否足够,怎么处理符号位)
4、计算10000或者更大数字的阶乘问题(算法,溢出,如何判断溢出)
5、实现手机后四位查找功能
6、

技能:
1、load飙高的常见排查思路

来自 Google 官方的代码评审最佳实践-摘录

  • 文章地址
  • CR的标准
  • 在 CR 中要看些什么
  • 如何浏览这次改动(CL)
  • Review 的速度
  • CR 要多快?
  • 速度 vs 中断
  • 快速回应

文章地址

原文地址:https://mp.weixin.qq.com/s/zIiDk7rcIKgvqh0YAvQPaA

英文地址:https://github.com/google/eng-practices/

CR的标准

  • Reviewer 有责任保证CL的质量,作为Review的代码的Owner
  • Reviewer不应追求完美,而应追求持续改进
  • CR要具有指导意义
  • 代码风格应该与现有的一致。如果项目没有统一风格,那就接受作者的风格
  • 解决冲突难以达成共识时,需要面对面或者拉起更大的团队讨论,带上Leader

在 CR 中要看些什么

  • 代码经过完善的设计
  • 功能性对于使用者们是好的
  • 对于任何UI改动要合理且好看
  • 任何并行编程的实现是安全
  • 代码不应该复杂超过原本所必须的
  • 开发者不该实现一个现在不用而未来可能需要的功能
  • 代码有适当的单元测试
  • 测试经过完善的设计
  • 开发者对于每样东西有使用清晰、明了的命名
  • 注释要清楚且有用,并只用来解释why而非what
  • 代码有适当的写下文件(一般在g3doc)
  • 代码风格符合style guide
  • 确保你查看被要求review的每一行代码、确认上下文、确保你正在改善代码质量,并赞扬开发人员所做的好事与优点吧!

如何浏览这次改动(CL)

步骤1: 用宏观的角度来看待改动,查看CL描述以及它做什么步骤2: 检查CL主要的部分步骤3: 用合理的顺序看CL 其余的改动

Review 的速度

为什么 Review 速度要快?

在Google我们优化开发团队 共同生产产品的速度,而不是优化个人开发的速度。个人的开发速度很重要,但它不如整个团队的开发速度重要。

CR 如果很慢,则:

①、团队整体的速度下降。

②、开发人员开始抗议 cr。

③、代码质量会收到影响。review 慢时,开发者提交的压力大。

CR 要多快?

如果你并没有处于需要专注工作的时候,那么应该在 review 完后尽快修改。回复最长的极限是一个工作日。

速度 vs 中断

我们可以在投入到处理他人给的review评论之前,找个适当的时机点来进行cr。这有可能是当你的当前开发任务完成后、午餐、刚从会议脱身或从微型厨房回来等等。

快速回应

个人回应评论的速度,比起让整个 cr 过程快速结束更重要。

 若在整个过程中能快速获得来自 reviewer 的回应,大大减轻开发者对缓慢 cr 过程的挫败感。

 reviewer员要花足够的时间来进行review,确保他们给出的LGTM,意味着“此代码符合我们的标准”。

 理想的个人的回应速度还是越快越好。