架构学习过程

2019年10月11日

• redis作为分布式锁只能保证AP

  分析：redis作为分布式锁在大多数情况下是没问题的，但是我们知道CAP原理，一致性，可用性，分区容错性在redis分布式架构中，我们其实保证的是AP模型，也就是尽可能的保证了redis的可用性，这在一般系统中当然是没问题的，哪怕有时候一致性有点问题（实际读到的数据不正确，或已经写入没读到）毕竟是作为缓存的存在，一定延迟可以接受，没读到可以再读数据库，这是没问题的。但在分布式锁中，一旦出现该读到没读到，那就是重复锁的问题了，相当于分布式锁没起到作用。这种情况发生在什么时候呢？redis集群主节点再获取锁后，没来得及复制数据给从节点，此时宕机了，从节点接替主节点进行读写，此时新的主节点没有持有该锁，那么其他想要获取该锁的服务也可以获取到该锁，导致了重复锁的问题。一般来讲这种情况发生的概率是很小的，看你系统的规模而定，我觉得像阿里这种规模就应该不会用redis来作为分布式锁了CP模型的分布式锁可以用zookeeper，可能性能略低于redis，但能保证安全，可以提供顺序锁等额外功能。
  结论：redis其实不适合作为分布式锁的第一选择
  知识点：
  1、redis加锁与设置过期时间要作为一个原子操作，防止获取锁后，线程挂了，导致永远不释放锁，高版本redis，都支持setnx的加锁+设置超时时间在一个原子操作内。
  2、redis释放锁的时候，在一个极端场景，假如某A线程成功得到了锁，并且设置的超时时间是30秒。如果某些原因导致线程A执行的很慢很慢，过了30秒都没执行完，这时候锁过期自动释放，线程B得到了锁。随后，线程A执行完了任务，线程A接着执行del指令来释放锁。但这时候线程B还没执行完，线程A实际上删除的是线程B加的锁。怎么避免这种情况呢？可以在del释放锁之前做一个判断，验证当前的锁是不是自己加的锁。至于具体的实现，可以在加锁的时候把当前的线程ID当做value，并在删除之前验证key对应的value是不是自己线程的ID。

  加锁：
  String threadId = Thread.currentThread().getId()
  set（key，threadId ，30，NX）
  
  doSomething.....
   
  解锁：
  if（threadId .equals(redisClient.get(key))）{
      del(key)
  }

  3、raft在redis内并没有用来实现一些分布式锁以及分布式事务，仅仅是用来做master宕机时的选主，可能后续的版本会逐渐支持。在redis内部有一个哨兵(sentinel)监测master和slave的状态，当有一个master节点宕机的时候，sentinel就会在剩下的slave中选择一个合适的节点作为master。
  
  

• 新浪微博与微信朋友圈
  PUSH：及时推送消息
  PULL：用户上线再推送消息
  谢娜有几千万粉丝，新浪微博热门不能实时推送，适合用户登录再推送；

• 网关层的作用
  

2019年10月21日：

微服务架构的痛点：

• 业务关注服务间通信-->应用服务需要引入各种jar包去实现熔断\限流\降级、服务注册发现、服务重试等-->业务迭代速度慢
• 基础设施组件升级困难-->影响基础设施团队的交付能力和速度
• 多编程语言之间的通信问题

Service Mesh：服务网格架构设计与实践：服务网格是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑关系，服务网格负责在这些拓扑中实现请求的可靠传递，在实践中，服务网格通常实现为一组轻量级网络代理，他们和应用程序部署在一起，对应用程序透明

• ServiceMesh架构

 

• 微服务高可用设计手段

2019年10月24日：

• 数据库什么时候会放弃本可以使用索引的场景？
  当数据库发现查询的数据量过大时（比如查询量超过全表的50%），使用索引还不如遍历全表，就会放弃索引

2019年11月04日：

• 如何做灰度发布：

2019年11月07日：

1、注册中心设计与实践：

• ZK是CP模型，一般设计需满足60%以上的节点可用才能提供服务，保证的是一致性（Eureka是AP模型，最终一致性，保证的是可用性，Eureka2.0官方不再更新支持，1.0持续支持），注册中心的本质：根据服务名得到ip+port
• ZK作为注册中心缺点：1.当服务规模超过一定数量，ZK将不堪重负：因为服务注册从节点大量写；2.服务与注册中心的TCP长连接；3、写是单点，不能水平扩容（只能按照业务功能垂直拆分ZK集群）；4、服务假死问题；5、服务TCP长连接探活只是一个ping效果一般

机房3因为网络问题整体与机房1、机房2失去联系，这个时候会导致机房3中部署的ServiceA无法再调用任何ServiceB服务，包括与自己同一机房部署的ServiceB，如果1，2，3机房全部失去联系，ZK为了保证一致性，整体服务都不可用，这就是脑裂嘛，回头我再学习下脑裂的知识点，忘了~

综上，ZK有时候不适合作为注册中心，怎么办，自研~

2019年11月11日：

• Gossip协议：P2P 网络核心技术：Gossip 协议 - 简书
• Gossip协议对比Zab\Raft：Zab\Raft主节点需要与所有从节点一一通信同步数据，当从节点很大时，主节点通信压力很大。而Gossip 协议中的消息会以一传十、十传百一样的指数级速度在网络中快速传播，因此系统状态的不一致可以在很快的时间内收敛到一致。消息传播速度达到了 logN。
• Gossip如何知道其他随机的通信节点呢：广播机制

2019年11月13日：

2、配置中心设计与实践：

携程Apollo：监听器模式、AP模型

2019年11月21日：

Docker解决什么问题？

• 资源共享
• 进程资源隔离
• Docker是共享Host的内核的，Docker是通过namespace和cgroup来做资源隔离的

容器云平台：

• 资源隔离
• 弹性扩缩容
• 资源利用率
• 研发效率提升

2019年11月28日

分库分表举例：信用卡（身份证、卡号、申请时间等等）：5亿条记录，分库分表后查询（需要能根据身份证、卡号）怎么办？partition key如何选择，因为partition key只能选择一个？按照身份证分表，那么如果需要根据卡号查询，则需要遍历所有分表；这个时候需要建立一个映射表，映射卡号-->身份证的映射，再根据映射表的结果查询。如果要按照时间查询呢？一切脱离业务需求的设计都是耍流氓

全程预期：2019年10月10~2020年02月28学习完成，尽量年前吧~