网站盈利模式有哪几种,wordpress 数据库链接,html做的网页怎么变成网站,免费咨询兽医转载自 分布式架构#xff0d;#xff0d;基本思想汇总 在互联网大行其道的今天#xff0c;各种分布式系统已经司空见惯。搜索引擎、电商网站、微博、微信、O2O平台。。凡是涉及到大规模用户、高并发访问的#xff0c;无一不是分布式。 关于分布式系统#xff0c;并没有…转载自  分布式架构基本思想汇总 在互联网大行其道的今天各种分布式系统已经司空见惯。搜索引擎、电商网站、微博、微信、O2O平台。。凡是涉及到大规模用户、高并发访问的无一不是分布式。 关于分布式系统并没有一个标准答案说某某架构一定是最好的。不同的业务形态所面对的挑战不一样使用的架构设计也不一样通常都需要具体业务具体分析。 但不管那种业务不管何种分布式系统有一些基本的思想还是相通的。本文将对这些基本思想进行一个梳理汇总。 分拆 系统分拆 微信的架构师说过一句话“大系统小做“。对于一个大的复杂系统首先想到的就是对其分拆拆成多个子系统。每个子系统自己的存储/Service/接口层各个子系统独立开发、测试、部署、运维。  从团队管理角度讲也可以不同团队用自己熟悉的语言体系团队之间基于接口进行协作职责清晰各司其职。 子系统分拆 拆成子系统之后子系统内部又可以分层分模块。当然这里“系统““子系统““层““模块“ 都只是一个相对概念。在一个系统里面某个模块复杂到一定程度会把它抽出来单独做成一个系统而在初期很大简单模块可能不回拆分集中在一个系统里面。  这就像一个生物组织自身是在不断成长、演化、有分有合不断变化发展的。 存储分拆 Nosql对于Nosql数据库比如MongoDB其天生就是分布式的很容易实现数据的分片。  Mysql: 对于Mysql或者其它关系型数据库就会设计到分库分表。而分库分表就会涉及到几个关键性的问题切分维度join的处理分布式事务 计算分拆 计算的分拆有2种思路  数据分拆一个大的数据集拆分成多个小的数据集并行计算。  比如大规模数据归并排序 任务分拆把一个长的任务拆分成几个环节各个环节并行计算。 Java中多线程的Fork/Join框架Hadoop中的Map/Reduce都是计算分拆的典型框架。其思路都是相似的先分拆计算再合并结果。 再比如分布式的搜索引擎中数据分拆分别建索引查询结果再合并。 并发 最常见的就是多线程尽可能提高程序的并发度。  比如多次rpc顺序调用通过异步rpc转化为并发调用  比如数据分片你的一个Job要扫描全表跑几个小时数据分片用多线程性能会加快好几倍。 缓存 缓存大家都不陌生遇到性能问题大家首先想到的就是缓存。关于缓存一个关键点就是缓存的粒度问题。 比如Tweet的架构缓存的粒度从小到大有Row Cache, Vector Cache, Fragment Cache, Page Cache。 粒度越小重用性越好但查询需要多次需要数据拼装  粒度越大越容易会失效任何一个小的地方改动都可能造成缓存的失效。 在线计算 vs. 离线计算 / 同步 vs. 异步 在实际的业务需求中并不是所有需要都需要完全实时的  比如内部针对产品、运营开发的各种报表查询、分析系统  比如微博的传播我发了一个微博我的粉丝延迟几秒才看到这是可以接受的因为他并不会注意到晚了几秒  比如搜索引擎的索引我发了一篇博客可能几分钟之后才会被搜索引擎索引到  比如支付宝转帐、提现也并非这边转出之后对方立即收到  。。。 这类例子很多。这种“非实时也可以接受“的场景就为架构的设计赢得了充分的回旋余地。 因为非实时我们就可以做异步比如使用消息队列比如使用后台的Job周期性处理某类任务 也因为非实时我们可以做读写分离读和写不是完全同步比如Mysql的Master-Slave。 全量 增量 全量/增量其实也是在线/离线的思路  比如搜索引擎的全量索引 增量索引前者是为了吞吐后者为了实时  比如OceanBase数据库每次更新存在一个小表里面定期merge Push vs. Pull 在所有分布式系统中都涉及到一个基本问题节点之间或者2个子系统之间的状态通知。比如一个节点状态变更了要通知另外一个节点都有2种策略  Push: 节点A状态变了 push给节点B  Pull: 也就是轮询。节点B周期性的去询问节点A的状态。 这个问题不光出现在分布式系统中可以说是编写代码的一个基本问题。对应到面向对象的编程中也就是常说的“双向关联”这种耦合问题。 A调用BB再回调A这种情形在系统开发中经常出现。再复杂一点多个模块之间彼此调用调用关系跟蜘蛛网一样。 这个问题的出现就和Push/Pull的策略密切相关  A调用B那逻辑就会写在B这边B调用A逻辑就会写在A这边。所以是采用主动调用的pull方式还是回调的push方式会严重影响职责在各个模块或者子系统里面的分配。 批量 批量其实也是在线/离线的一种思想把实时问题转化为一个批量处理的问题从而降低对系统吞吐量的压力  比如Kafka中的批量发消息  比如广告扣费系统中把多次点击累积在一起扣费  。。 重写轻读 vs 重读轻写 重写轻读本质就是“空间换时间“。你不是计算起来耗时延迟高吗那我可以提前计算然后存储起来。取的时候直接去取。 我们通常对Mysql的用法都是重读轻写写的时候简单查的时候做复杂的join计算返回结果。这样做的好处是容易做到数据的强一致性不会因为字段冗余造成数据的不一致。但是性能可能就是问题。 而微博的Feeds架构就是典型的重写轻读。我要去看Feeds按通常的mysql的做法我要先去查我关注的所有的人然后把所有人的消息排序分页返回。很显然在大数据量下这个会很耗时。  而如果采用重写轻读怎么做呢你不是要看Feeds吗那就为每个人准备一个Feeds或者说收件箱。某个人发了微博之后把他的微博扩散到所有人的收件箱这个扩散是异步的在后台扩散。这样每个人看自己的Feeds的时候直接去自己的收件箱取就可以了。 读写分离 同样对传统的单机Mysql数据库读和写是完全同步的。写进去的内容立马就可以读到。  但在很多业务场景下读和写并不需要完全同步。这个时候就可以分开存储写到一个地方再异步的同步到另一个地方。这样就可以实现读写分离。  比如Mysql的Master/Slave就是个典型Slave上面的数据并不是和Master实时同步的  再比如各种报表分析OLTP/OLAP线上/线下数据分离线上数据定期同步到Hive集群再做分析。 动静分离 动静分离的典型例子就是网站的前端动态的页面放在web服务器上静态的css/jss/img直接放到CDN上这样既提高性能也极大的降低服务器压力。 按照这个思路很多大型网站都致力于动态内容的静态化静态化之后就可以很容易的缓存。 冷热分离 比如定期把mysql中的历史数据同步到hive 限流 现在很多电商都会有秒杀活动秒杀的一个特点就是商品很少但短时间内流量暴增服务器完全处理不了这么多请求。 应对这类问题的一个基本思路就是限流既然处理不了那么多请求既然很大人进去了也是抢不到的。那索性不要放那么多人进去。 这个和我们日常生活中节假日某个景点人数过多限制人流量是同样的道理。 服务熔断与降级 服务降级是系统的最后一道保险。在一个复杂系统内部一个系统往往会调用其它很大系统的服务。在大流量的情况下我们可能会在保证主流程能正常工作的情况下对其它服务做降级。 所谓降级也就是当某个服务不可用时干脆就别让其提供服务了直接返回一个缺省的结果。虽然这个服务不可用但它不至于让整个主流程瘫痪这就可以最大限度的保证核心系统可用。 CAP理论 上面讲的各种思想用一个更大的思想来概括的话就是CAP。 Consistency数据一致性这个很容易理解就是没有脏数据。我们知道在Mysql中有一致性的概念比如参照完整性约束、事务等。但这里的C主要特指同1份数据的多个备份之间的一致性。 Availability可用性有2重意思一个是说稳定性服务可用不会挂另外一个是性能也就是要快如果延迟很高经常超时那和挂了也就区别不大了。 Partition tolerance(分区容错性)分区其实指网络分区。当你把数据从1个物理设备分到多个物理设备之后设备之间必然是通过网络进行通信。这就会遇到网络分区也就是典型的“2将军问题“网络超时时间不定。学术上有个词叫“异步通信环境“。 以前说CAP理论说对于一个分布式系统上面3个只能同时满足2个。但这个其实不准确P其实一定存在是你避免不了的。能做的其实主要是在C和A之间权衡。 比如拿Mysql来说它的C最强A次之P最弱。如果你为了A给数据做冗余比如重写轻读那C就很难保证为了P给数据做分库分表那就做不了事务 比如NosqlP最强可以很好的做数据拆分但C就不够做不了事务 比如微博系统对C的要求降低就可以加很多缓存提高A数据分片提高P 而支付交易转帐对C的要求很高就不能简单的用Cache来提高性能 在此我向大家推荐一个架构学习交流群。交流学习群号190713474 点击原文链接加群里面会分享一些资深架构师录制的视频录像有SpringMyBatisNetty源码分析高并发、高性能、分布式、微服务架构的原理JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源目前受益良多 最终一致性 前面提到在分布式系统中因为数据的分拆服务的分拆强一致性就很难保证。这个时候用的最多的就是“最终一致性“。 强一致性弱一致性最终一致性是一致性的几个不同的等级。在传统的关系型数据库中通过事务来保证强一致性。 但在分布式系统中通常都会把强一致性折中成最终一致性从而变相的解决分布式事务问题。 典型的转帐的例子A给B转帐1万块钱A的账号扣1万B的账号加1万。但这2步未必需要同时发生, A的扣完之后B的账号上面未必立马就有但只要保证B最终可以收到就可以了。 最终一致性的实现通常都需要一个高可靠的消息队列。关于这个网上有各种分享文章后续也会对这个问题单独阐述。