场景题
个人理解问题:为了避免myqsl死锁,应该注意什么?
事务的提交
项目如何设计保证高可用和系统稳定性
- 架构设计,不同的系统对系统指标的侧重点不同,系统架构有很多不同的设计是不是要折中考量一下,比如数据存储,服务治理,中间件等等
- 消除单点,避免应用程序、数据库、缓存等服务器有单点的情况存在
- 数据一致性,要有分段提交,补偿机制来保证幂等性和最终一致性
- 避免强依赖,一旦依赖的系统挂掉,调用方也能用会挂掉,强依赖越少,系统稳定性越高。
- 热点数据,对热点数据进行缓存预热,分库分表
- 异常处理,要尽可能多的考虑异常情况,和如何处理
- 容量评估,通过监控日常进件的数量和压测来对系统进行适当扩容
- 运维方案,能检测服务的运行情况,对异常情况进行报警,如果生产出现重大问题可以快速回滚
- 安全设计,如防止sql注入,参数合法性校验,黑名单机制,信息脱敏等
- 良好的流程制度,代码review,单元测试,回归测试,上线发布审核,报警值班,定期压测,错误日志排查等等
- 个人意识和能力,永远敬畏线上,敬畏用户体验,只要职责在就要守护好。
如果有一个复杂且流程很长的业务你能想到的问题及对应的解决方案
redis和MySQL怎么保存缓存一致性
canal
短链的实现方法
分布式ID
幂等性:就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的,不会因为多次点击而产生了副作用。
cap理论
C:数据一致性
A:服务可用性
P:分区容错性
CAP理论
Consistency(一致性)
即更新操作成功后,所有节点在同一时间的数据完全一致。
对于客户端来说,一致性指的是并发访问时更新过的数据如何获取的问题。
对于服务端来说,一致性指的是更新过的数据如何复制分布到整个系统,以保证数据最终一致。
Availability(可用性)
即服务一直可用,而且是正常响应时间。系统能够很好地为用户服务,不出现用户操作失败或者访问超时等用户体验不好的情况。
Partition Tolerance(分区容错性)
即分布式系统在遇到某个节点或者网络分区故障的时候仍然能够对外提供满足一致性和可用性的服务。分区容错性要求能够使应用虽然是一个分布式系统,而看上去却好像是一个可以正常运转的整体。
BASE理论
BASE理论是基于CAP理论逐步演化而来的,是CP(强一致性)和AP(强可用性)权衡的结果。
BASE理论的核心思想是:即使无法做到强一致性,但每个应用都可以根据自身业务特点采用适当的方式来使系统达到最终一致性。
Basically Available(基本可用)
响应时间上的损失:正常情况下,处理用户请求需要0.5s返回结果,但是由于系统出现故障,处理用户请求的时间变成3s。
系统功能上的损失:正常情况下,用户可以使用系统的全部功能,但是由于系统访问量突然剧增,系统的非核心功能无法使用。
Soft state(软状态)
数据同步允许一定的延迟。
Eventually consistent(最终一致性)
系统中所有的数据副本,在经过一段时间的同步后,最终能够达到一个一致的状态,不要求实时。
cpu密集型
cpu密集型指的是cpu运算多,io操作少
io密集型
io频繁,cpu运算少
有状态服务和无状态服务
有状态:请求2所需要的数据依赖请求1
无状态:请求2所需要的数据依赖于请求2本身,或其他外部数据源
32位系统与64位系统有啥区别