分布式架构

分布式存储往往采用分布式的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息。它不但提高了系统的可靠性、可用性和存取效率，还易于扩展，将通用硬件引入的不稳定因素降到最低。优点如下： 分布式存储的六大优点 1. 高性能 一个具有高性能的分布式存户通常能够高效地管理读缓存和写缓存，并且支持自动的分级存储。分布式存储通过将热点区域内数据映射到高速存储中，来提高系统响应速度;一旦这些区域不再是热点，那么存储系统会将它们移出高速存储。而写缓存技术则可使配合高速存储来明显改变整体存储的性能，按照一定的策略，先将数据写入高速存储，再在适当的时间进行同步落盘。 2. 支持分级存储 由于通过网络进行松耦合链接，分布式存储允许高速存储和低速存储分开部署，或者任意比例混布。在不可预测的业务环境或者敏捷应用情况下，分层存储的优势可以发挥到最佳。解决了目前缓存分层存储最大的问题是当性能池读不命中后，从冷池提取数据的粒度太大，导致延迟高，从而给造成整体的性能的抖动的问题。 3. 多副本的一致性 与传统的存储架构使用RAID模式来保证数据的可靠性不同，分布式存储采用了多副本备份机制。在存储数据之前，分布式存储对数据进行了分片，分片后的数据按照一定的规则保存在集群节点上。为了保证多个数据副本之间的一致性，分布式存储通常采用的是一个副本写入，多个副本读取的强一致性技术，使用镜像、条带

场景 什么是分布式系统 分布式系统是若干独立计算机的集合，这些计算机对于用户来说就像单个相关系统。 分布式系统是建立在网络之上的软件系统。 注： 博客： https://blog.csdn.net/badao_liumang_qizhi 关注公众号 霸道的程序猿 获取编程相关电子书、教程推送与免费下载。 实现 单一应用架构 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。 单一应用结构特点 适用于小型网站，小型管理系统，将所有功能都部署到一个功能里，简单易用。 缺点： 1、性能扩展比较难 2、协同开发问题 3、不利于升级维护 垂直应用结构 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC)是关键。 垂直应用结构特点 通过切分业务来实现各个模块独立部署，降低了维护和部署的难度，团队各司其职更易管理，性能扩展也更方便，更有针对性。 缺点： 公用模块无法重复利用，开发性的浪费 分布式服务架构 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。

Scrapy-Redis分布式爬虫 介绍 scrapy-redis巧妙的利用redis 实现 request queue和 items queue，利用redis的set实现request的去重，将scrapy从单台机器扩展多台机器，实现较大规模的爬虫集群 scrapy-redis是基于redis的scrapy组件 • 分布式爬虫 多个爬虫实例分享一个redis request队列，非常适合大范围多域名的爬虫集群 • 分布式后处理 爬虫抓取到的items push到一个redis items队列,这就意味着可以开启多个items processes来处理抓取到的数据，比如存储到Mongodb、Mysql • 基于scrapy即插即用组件 Scheduler + Duplication Filter, Item Pipeline, Base Spiders. scrapy-redis架构 • 调度器(Scheduler) scrapy-redis调度器通过redis的set不重复的特性，实现了Duplication Filter去重（DupeFilter set存放爬取过的request）。 Spider新生成的request，将request的指纹到redis的DupeFilter set检查是否重复，并将不重复的request push写入redis的request队列。

这两天正在研究微服务架构中分布式事务的处理方案, 做一个小小的总结, 作为备忘. 如有错误, 欢迎指正! 概念澄清 事务补偿机制: 在事务链中的任何一个正向操作, 都必须存在一个完全符合回滚规则的可逆操作, 这个操作通常叫做rollback或者cancel. CAP理论: CAP(Consistency, Availability, Partition Tolerance), 阐述了一个分布式系统的三个主要方面, 只能同时择其二进行实现. 常见的有CP系统, AP系统. 为什么CA不行呢? 因为没有P的话, 数据一致性会出现问题, 这是任何一个一致性系统不允许出现的情况. 幂等性: 简单的说, 业务操作支持重试, 不会产生不利影响. 常见的实现方式: 为消息额外增加唯一ID. BASE(Basically avaliable, soft state, eventually consistent): 是分布式事务实现的一种理论标准. 柔性事务 vs. 刚性事务 刚性事务是指强一致性事务, 例如单机环境下遵循ACID的数据库事务, 或者分布式环境中的2PC等. 柔性事务是指遵循BASE理论的事务, 通常用在分布式环境中, 常见的实现方式有: 异步确保型, 最大努力通知型. 最佳实践 先上结论, 再分别介绍分布式事务的各种实现方式. 如果业务场景需要强一致性,

分片（水平拆分） 2.取模分片（mod-long） cd /data/mycat/conf cp schema.xml schema.xml.rang-long vi schema.xml <?xml version="1.0"?> <!DOCTYPE mycat:schema SYSTEM "schema.dtd"> <mycat:schema xmlns:mycat="http://io.mycat/"> <schema name="TESTDB" checkSQLschema="false" sqlMaxLimit="100" dataNode="sh1"> <table name="t4" dataNode="sh1,sh2" rule="mod-long" /> </schema> <dataNode name="sh1" dataHost="oldguo1" database= "taobao" /> <dataNode name="sh2" dataHost="oldguo2" database= "taobao" /> <dataHost name="oldguo1" maxCon="1000" minCon="10" balance="1" writeType="0" dbType="mysql" dbDriver="native" switchType="1">

参考地址： https://www.cnblogs.com/ultranms/p/9585191.html 在Zookeeper的官网上有这么一句话：ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. 这大概描述了Zookeeper主要可以干哪些事情：配置管理，名字服务，提供分布式同步以及集群管理。那这些服务又到底是什么呢？我们为什么需要这样的服务？我们又为什么要使用Zookeeper来实现呢，使用Zookeeper有什么优势？接下来我会挨个介绍这些到底是什么，以及有哪些开源系统中使用了。 配置管理 在我们的应用中除了代码外，还有一些就是各种配置。比如数据库连接等。一般我们都是使用配置文件的方式，在代码中引入这些配置文件。但是当我们只有一种配置，只有一台服务器，并且不经常修改的时候，使用配置文件是一个很好的做法，但是如果我们配置非常多，有很多服务器都需要这个配置，而且还可能是动态的话使用配置文件就不是个好主意了。这个时候往往需要寻找一种集中管理配置的方法，我们在这个集中的地方修改了配置，所有对这个配置感兴趣的都可以获得变更

老套路 1、什么是Redis 2、为什么要用Redis 3、怎么用Redis 4、使用Redis过程中遇到的问题 1、什么是Redis 　　介绍Redis之前先了解一下Nosql（非关系型数据库） 　　我们都知道MySql是一种关系型数据库，那什么是非关系型数据库呢？它又是做什么呢？ 　　为了解决高并发、高可用、高可扩展，大数据存储等一系列问题而产生的数据库解决方案，就是NoSql。它不能替代关系型数据库，只能作为关系型数据库的一个良好补充。 　　Redis是使用c语言开发的一个高性能 键值数据库 。Redis通过 键值类型 存储数据。 　　 Redis使用场景 ：缓存（数据查询、短连接、新闻内容、商品内容等等） 　　（最多使用） 分布式集群架构中的session分离 　　聊天室的在线好友列表 　　任务队列 　　（秒杀、抢购、12306等等） 应用排行榜 　　网站访问统计 　　数据过期处理（可以精确到毫秒） 2、为什么要用Redis 　　为了解决高并发、高可用、高可扩展，大数据存储等一系列问题，MySql不能很好为我们提供服务，引入了Redis。 　　那么为什么要用Redis呢？ 　　1、速度快：首先Redis由C语言编写，纯内存操作，第二个 核心是基于非阻塞的IO多路复用机制，单线程避免了多线程的频繁上下文切换问题 　　2、支持多种数据类型，5种数据类型： String、Hash

一、什么是分布式架构 　　分布式系统（distributed system） 是建立在网络之上的软件系统。 　　内聚性：是指每一个数据库分布节点高度自治，有本地的数据库管理系统。 　　透明性：是指每一个数据库分布节点对用户的应用来说都是透明的，看不出是本地还是远程。 　　 　　在分布式数据系统中，用户感觉不数据是分布的，即用户不须知道关系是否分割，有无副本，数据存在于那个站点以及事物在哪个站点上执行。 　　简单来说：在一个分布式系统中，一组独立的计算机展现给用户的是一个统一的整体，就好像是一个系统似的。 　　 分布式系统作为一个整体对用户提供服务，而整个系统的内部的协作对用户来说是透明的，用户就像是指使用一个mysql 一样。 如：分布式mysql中间件 mycat ,来处理大并发大数据量的构架。 二、分布式架构的应用 　　1、分布式文件系统 　　　　例如：出名的有 Hadoop 的 HDFS, 还有 google的 GFS , 淘宝的 TFS 等 　　2、分布式缓存系统 　　　　例如：memcache , hbase, mongdb 等 　　3、分布式数据库 　　　　例如：mysql, mariadb, postgreSql 等 　　4、分布式webService 　　5、分布式计算 　　 举例 　　　　以分布式mysql 数据库中间件mycat 为例　　　　 　　　　MySQL

SpringCloud分布式微服务云架构 第五篇: 路由网关(zuul)(Finchley版本) 在微服务架构中，需要几个基础的服务治理组件，包括服务注册与发现、服务消费、负载均衡、断路器、智能路由、配置管理等，了解springcloud架构可以加求求：三五三六二四七二五九，由这几个基础组件相互协作，共同组建了一个简单的微服务系统。一个简答的微服务系统如下图： 注意：A服务和B服务是可以相互调用的，并且配置服务也是注册到服务注册中心的。 在Spring Cloud微服务系统中，一种常见的负载均衡方式是，客户端的请求首先经过负载均衡（zuul、Ngnix），再到达服务网关（zuul集群），然后再到具体的服务统一注册到高可用的服务注册中心集群，服务的所有配置文件由配置服务管理（下一篇文章讲述），配置服务的配置文件放在git仓库，方便开发人员随时改配置。 一、Zuul简介 Zuul的主要功能是路由转发和过滤器。路由功能是微服务的一部分，比如／api/user转发到到user服务，/api/shop转发到到shop服务。zuul默认和Ribbon结合实现了负载均衡的功能。 zuul有以下功能： Authentication Insights Stress Testing Canary Testing Dynamic Routing Service Migration Load

YARN产生背景 YARN是Hadoop2.x才有的，所以在介绍YARN之前，我们先看一下MapReduce1.x时所存在的问题： 单点故障 节点压力大 不易扩展 MapReduce1.x时的架构如下： 可以看到，1.x时也是Master/Slave这种主从结构，在集群上的表现就是一个JobTracker带多个TaskTracker。 JobTracker：负责资源管理和作业调度 TaskTracker：定期向JobTracker汇报本节点的健康状况、资源使用情况以及作业执行情况。还可以接收来自JobTracker的命令，例如启动任务或结束任务等。 那么这种架构存在哪些问题呢： 整个集群中只有一个JobTracker，就代表着会存在单点故障的情况 JobTracker节点的压力很大，不仅要接收来自客户端的请求，还要接收大量TaskTracker节点的请求 由于JobTracker是单节点，所以容易成为集群中的瓶颈，而且也不易域扩展 JobTracker承载的职责过多，基本整个集群中的事情都是JobTracker来管理 1.x版本的整个集群只支持MapReduce作业，其他例如Spark的作业就不支持了 由于1.x版本不支持其他框架的作业，所以导致我们需要根据不同的框架去搭建多个集群。这样就会导致资源利用率比较低以及运维成本过高，因为多个集群会导致服务环境比较复杂。如下图：