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学习完成,尽量年前吧~