分布式架构

前言 相信大家对 ZooKeeper 应该不算陌生。但是你真的了解 ZooKeeper 是个什么东西吗？如果别人/面试官让你给他讲讲 ZooKeeper 是个什么东西，你能回答到什么地步呢？ 我本人曾经使用过 ZooKeeper 作为 Dubbo 的注册中心，另外在搭建 solr 集群的时候，我使用到了 ZooKeeper 作为 solr 集群的管理工具。前几天，总结项目经验的时候，我突然问自己 ZooKeeper 到底是个什么东西？想了半天，脑海中只是简单的能浮现出几句话：“①Zookeeper 可以被用作注册中心。 ②Zookeeper 是 Hadoop 生态系统的一员；③构建 Zookeeper 集群的时候，使用的服务器最好是奇数台。” 可见，我对于 Zookeeper 的理解仅仅是停留在了表面。 所以， 通过本文，希望带大家稍微详细的了解一下 ZooKeeper 。如果没有学过 ZooKeeper ，那么本文将会是你进入 ZooKeeper 大门的垫脚砖。如果你已经接触过 ZooKeeper ，那么本文将带你回顾一下 ZooKeeper 的一些基础概念。 最后， 本文只涉及 ZooKeeper 的一些概念，并不涉及 ZooKeeper 的使用以及 ZooKeeper 集群的搭建。 网上有介绍 ZooKeeper 的使用以及搭建 ZooKeeper 集群的文章

一、微服务架构基本知识(spring-cloud) 1.1 什么是分布式? 不同模块部署在不同服务器上,对系统的水平拓展,分散单个服务器压力. 作用：分布式解决网站高并发带来问题 1.2 什么是集群? 多台服务器部署相同应用构成一个集群,利用硬件优势支撑访问量高的应用. 作用：通过负载均衡设备共同对外提供服务 1.3 什么是微服务? 微服务是对系统进行更细粒度的拆分，侧重于模块解耦和复用，不同的微服务不一定部署到不同服务器上，微服务是使系统各个功能拆分更加精细和独立的垂直拓展。 架构设计概念,各服务间隔离（分布式也是隔离）,自治（分布式依赖整体组合）,其它特性(单一职责,边界,异步通信,独立部署),微服务是分布式概念的更严格执行.换句换说:微服务一定是分布式的,但分布式项目不一定是微服务架构! 二、微服务架构图 三、SpringCloud说明 SpringCloud 为开发人员提供了快速构建分布式(或微服务)系统的一些工具，包括配置管理（config）、服务发现(Eureka)、断路器(hystrix)、路由(zuul)、微代理http客户端(Feign,rpc远程调用)、事件总线(Bus)、负载均衡（Ribbon,rpc远程调用）、日志链路监控（Zipkin）等。 四、服务生产者与消费者的关系 服务生产者:提供服务被人调用; 服务消费者:调用别人服务. 五、概念介绍完

NoSql数据库四大分类 键值存储 列存储 文档数据库 图形数据库 NoSQL的特点 易扩展 灵活的数据模型 大数据量，高性能 高可用 Redis 读10w/s 写8w/s Redis的应用场景 缓存 任务队列 网站访问统计 应用排行榜 数据过期处理 分布式集群架构中的session分离 来源： https://www.cnblogs.com/Roni-i/p/10802222.html

CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。 而由于当前的网络硬件肯定会出现延迟丢包等问题，所以 分区容忍性是我们必须需要实现的。 所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。 ======================================================================================================================= C:强一致性 A：高可用性 P：分布式容忍性 CA 传统Oracle数据库 AP 大多数网站架构的选择 CP Redis、Mongodb 注意：分布式架构的时候必须做出取舍。 一致性和可用性之间取一个平衡。多余大多数web应用，其实并不需要强一致性。 因此牺牲C换取P，这是目前分布式数据库产品的方向 ======================================================================================================================= 一致性与可用性的决择 对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地 数据库事务一致性需求 　　很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，

MongoDB 4.2已经发布，我们来看看它增加了哪些新特性？分布式事务？数据库加密？通配符索引？ 在2019年MongoDB World大会上，CTO Eliot Horowitz介绍了MongoDB 4.2中的一些功能，这些功能扩展了其在数据库技术方面的领先地位：分布式事务（Distributed Transactions），字段级加密（Client Side Field Level Encryption），通配符索引（Wildcard Indexing）、按需物化视图（Materialized Views）。 这些都是重大的改进，表明MongoDB在企业级功能方便更加完善。 MongoDB 4.2提升了事务和分析技术水平。它提供大规模的分布式事务的ACID担保和复杂的数据处理流程，还有最先进的加密控制保护机制。我们可以在任何地方运行MongoDB4.2：在本地数据中心，云上、混合云、Atlas云上。我们可以获得阿里云、AWS，Azure和GCP可用的完全托管，云原生的MongoDB服务。阿里云全球第一个实现了MongoDB异地多活架构。可以支持互联网跨国公司的大规模出海业务。 现在使用MongoDB的公司越来越多了，技术架构方案也越来越成熟。MongoDB新特性也是为了满足更多的企业级业务场景需求。 1. MongoDB 4.2 新特性 先来大体上看看有哪些改进，作为4

原文网址：http://geek.csdn.net/news/detail/97879 【 摘要 】本文谈及一些分布式系统的理论和思想，包括 CAP、BASE、NWR 等。并简单分析一些主流数据库分布式方案的利弊，以便我们在开发时更深入全面地进行思考、选择和设计。以下为正文： 在讨论常见架构前，先简单了解下 CAP 理论： CAP是Consistency、Availablity和Partition-tolerance的缩写。分别指： 一致性（Consistency）：每次读操作都能保证返回的是最新数据； 可用性（Availablity）：任何一个没有发生故障的节点，会在合理的时间内返回一个正常的结果； 分区容忍性（Partition-tolerance）：当节点间出现网络分区，照样可以提供服务。 CAP理论指出：CAP三者只能取其二，不可兼得。其实这一点很好理解： 首先，单机系统都只能保证CP； 有两个或以上节点时，当网络分区发生时，集群中两个节点不能互相通信。此时如果保证数据的一致性C，那么必然会有一个节点被标记为不可用的状态，违反了可用性A的要求，只能保证CP； 反之，如果保证可用性A，即两个节点可以继续各自处理请求，那么由于网络不通不能同步数据，必然又会导致数据的不一致，只能保证AP。 一、单实例 单机系统很显然，只能保证CP，牺牲了可用性A。单机版的MySQL、Redis

通过优锐课的java架构学习分享中，讨论了让我们使用Redisson Java框架讨论六种不同类型的基于Redis的分布式队列。 在Redis中使用队列 Redis是一个功能强大的工具，支持从字符串和列表到映射和流的许多不同类型的数据结构。 开发人员将Redis用于多种目的，包括用于数据库，缓存和消息代理。 像任何消息代理一样，Redis需要以正确的顺序发送消息。 可以根据消息的年龄或某些其他预定义的优先级等级发送消息。 为了存储这些未决消息，Redis开发人员需要队列数据结构。 Redisson是使用Redis和Java进行分布式编程的框架，它提供了许多分布式数据结构（包括队列）的实现。 Redisson通过提供Java API使Redis开发更加容易。 Redisson不需要开发人员学习Redis命令，而是包括所有众所周知的Java接口，例如Queue和BlockingQueue。 Redisson还处理Redis中繁琐的幕后工作，例如连接管理，故障转移处理和数据序列化。 基于Redis的分布式Java队列 Redisson提供了Java中基本队列数据结构的多个基于Redis的实现，每种实现都有不同的功能。 这使你可以选择最适合你目的的队列类型。 下面，我们将使用Redisson Java框架讨论六种不同类型的基于Redis的分布式队列。 队列

1 分布式系统模型 1.1 什么是分布式系统，分布式系统的目标 定义： 分布式系统是若干独立计算机的集合，这些计算机对于用户来说就像是单个相关系统。 目标： 使资源可访问 透明性 开放性 可扩展性 1.2 为什么要分布式 经济性 微处理器能提供比大型机更好的性价比 速度 分布式系统能提供比大型机更强的计算能力 固有的分布性 有一些应用包含空间上分离的机器 可靠性 当某台机器崩溃时，整个系统仍能正常工作 可扩展性 计算能力逐步增加 1.3 分布式系统透明性和开放性的含义 透明性 定义： 在用户和应用程序面前呈现为单个计算机系统。 类型： 透明性 说明 访问 隐藏数据表示形式的不同以及资源访问访问的不同 位置 隐藏资源所在位置 迁移 隐藏资源是否移动到另一个位置 重定位 隐藏资源是否在使用过程中移动到另一个位置 复制 隐藏是否对资源进行复制 并发 隐藏资源是否由相互竞争用户共享 故障 隐藏资源的故障和恢复 透明度 将透明性和其他方面的问题结合起来考虑 开放性 不管底层环境如何，能够和其他开放系统进行交互 系统应该符合良好定义的接口 系统应该支持应用的可移植性 系统应该易于互操作 至少使分布式系统独立于底层环境的异构性 1.4 分布式操作系统、网络操作系统和基于中间件的系统 分布式操作系统 配置在分布式系统上的操作系统，能够直接对分布式系统中的各种资源进行动态分配

前言 最近的这段时间一直在学习Java EE，刚刚完成了从0到1的蜕变，所以顺便整理一下我所了解到的Java EE，给刚入门学习的新人一些头绪，而所谓“启示录”，就是这个意思。 一.Java EE是什么？ Java EE（Java Enterprise Edition）是一种 企业级应用的软件架构，同时是一种思想，一套规范。 二.Java EE的发展史 Java Enterprise Edition的发展不知不觉已经12年了，不知道大家有没留意，一开始，Java Enterprise Edition简称“J2EE”，直到版本5才改名为Java EE，而现在最新的版本则是Java EE 6。 到这里，或许有人会问，为什么会有这么多套Java EE规范？这些版本的差别是什么？ 1.J2EE1.2的出现，主要是将之前各个单独的规范绑定到一起。 2.J2EE1.3，则是继续完善J2EE体系结构。 3.J2EE1.4，主要是加入了一个重要主题：Web Service 4.而Java EE 5，主题则是“简化”，简化之前复杂的J2EE思想，改善开发体验。 三.Java EE到底要解决什么问题？ 1.Java EE解决什么问题？ 从Java EE发展背景看，它与“分布式应用”以及“互联网应用”的关系密不可分，而这两者也正是Java EE要解决的问题！ 其实

1. ElasticSearch ES即为了解决原生Lucene使用的不足，优化Lucene的调用方式，并实现了高可用的分布式集群的搜索方案，其第一个版本于2010年2月出现在GitHub上并迅速成为最受欢迎的项目之一。 首先，ES的索引库管理支持依然是基于Apache Lucene™的开源搜索引擎。 ES也使用Java开发并使用Lucene作为其核心来实现所有索引和搜索的功能，但是它的目的是通过简单的 RESTful API来隐藏Lucene的复杂性，从而让全文搜索变得简单。 不过，ES的核心不仅仅在于Lucene，其特点更多的体现为： 分布式的实时文件存储，每个字段都被索引并可被搜索 分布式的实时分析搜索引擎 KB-MB-GB-TB-PB 可以扩展到上百台服务器，处理PB级结构化或非结构化数据 高度集成化的服务，你的应用可以通过简单的 RESTful API、各种语言的客户端甚至命令行与之 交互。 上手Elasticsearch非常容易。它提供了许多合理的缺省值，并对初学者隐藏了复杂的搜索引擎理论。它拥有开瓶即饮的效果（安装即可使用），只需很少的学习既可在生产环境中使用。 1.1 ES的使用者及类似框架 典型使用案例 全球程序员github – 中国码云 ①Github(美国)使用Elasticsearch搜索20TB的数据，包括13亿的文件和1300亿行的代码.