通信协议 - 那些日常开发中经常听到用到的软件服务通信协议 - 学习实践

通信协议 - 那些日常开发中经常听到用到的软件服务通信协议 - 学习实践,第1张

通信协议 - 那些日常开发中经常听到用到的软件/服务通信协议 - 学习/实践

1.应用场景

主要用于学习那些日常开发中经常听到用到的软件/服务通信协议,弄清楚协议,通信协议有哪些,本质是什么,以及各自的应用场景。

2.学习/ *** 作

 

1.文档阅读

08 | 数据库优化方案(一):查询请求增加时,如何做主从分离?-极客时间

2.整理输出 2.1 MySQL通信协议

TBD

2.2 Redis通信协议

TBD

标准的MySQL通信协议是什么样子的, 另外我们使用Redis也可以看到Redis也有Redis通信协议,以及其他服务/软件,也是有各自的通信协议...


 

后续补充

...

3.问题/补充

1. 数据库主从读写分离【一定会涉及到主从复制,也伴随着主从同步的延迟问题,然后就引出了主从同步的数据一致性问题和取舍方案】

本节课,我带你了解了查询量增加时,我们如何通过主从分离和一主多从部署抵抗增加的数据库流量的,你除了掌握主从复制的技术之外,还需要了解主从分离会带来什么问题以及它们的解决办法。这里我想让你明确的要点主要有:

1. 主从读写分离以及部署一主多从可以解决突发的数据库读流量,是一种数据库横向扩展的方法;

2. 读写分离后,主从的延迟是一个关键的监控指标,可能会造成写入数据之后立刻读的时候读取不到的情况;

3. 业界有很多的方案可以屏蔽主从分离之后数据库访问的细节,让开发人员像是访问单一数据库一样,包括有像 TDDL、Sharding-JDBC 这样的嵌入应用内部的方案,也有像 Mycat 这样的独立部署的代理方案。

其实,我们可以把主从复制引申为存储节点之间互相复制存储数据的技术,它可以实现数据的冗余,以达到备份和提升横向扩展能力的作用。

在使用主从复制这个技术点时,你一般会考虑两个问题:

1. 主从的一致性和写入性能的权衡,如果你要保证所有从节点都写入成功,那么写入性能一定会受影响;如果你只写入主节点就返回成功,那么从节点就有可能出现数据同步失败的情况,从而造成主从不一致,而在互联网的项目中,我们一般会优先考虑性能而不是数据的强一致性。

2. 主从的延迟问题,很多诡异的读取不到数据的问题都可能会和它有关,如果你遇到这类问题不妨先看看主从延迟的数据。

我们采用的很多组件都会使用到这个技术,比如,Redis 也是通过主从复制实现读写分离;Elasticsearch 中存储的索引分片也可以被复制到多个节点中;写入到 HDFS 中文件也会被复制到多个 DataNode 中。只是不同的组件对于复制的一致性、延迟要求不同,采用的方案也不同。但是这种设计的思想是通用的,是你需要了解的,这样你在学习其他存储组件的时候就能够触类旁通了。

一课一思

我们提到,存储节点间互相复制数据是一种常见的,提升系统可用性和性能的方式,那么你还了解哪些组件有使用这种方式呢?它们的复制方式又是如何的呢?欢迎在留言区与我分享你的经验。

4.参考

TBD

后续补充

...

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/5694566.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-12-17
下一篇 2022-12-17

发表评论

登录后才能评论

评论列表(0条)

保存