分布式技术

Solr及SolrCloud简介 　　　　Solr是一个独立的企业级搜索应用服务器，它对外提供类似于Web-service的API接口。用户可以通过http请求，向搜索引擎服务器提交一定格式的XML文件，生成索引；也可以通过Http Get操作提出查找请求，并得到XML格式的返回结果。 　　　 SolrCloud是Solr4.0版本以后基于Solr和Zookeeper的分布式搜索方案，它的主要思想是使用Zookeeper作为集群的配置信息中心。它有以下几个特点： 集中式的配置信息管理。 自动容错。 近实时搜索。 查询时自动负载均衡。 将索引存储在HDFS上。 通过MR批量创建索引。 　　　　更多关于SolrCloud的相关介绍可参考以下链接： http://www.chepoo.com/solrcloud-introduction.html http://www.cnblogs.com/phinecos/archive/2012/02/10/2345634.html https://cwiki.apache.org/confluence/display/solr/SolrCloud 软件包准备 jdk-7u79-linux-x64.tar.gz apache-tomcat-7.0.62.tar.gz solr-5.2.1.tgz zookeeper-3.4.6.tar.gz

ASP.NET Core中间件实现分布式 Session 1. ASP.NET Core中间件详解 1.1. 中间件原理 1.1.1. 什么是中间件 1.1.2. 中间件执行过程 1.1.3. 中间件的配置 1.2. 依赖注入中间件 1.3. Cookies和session中间件 1.3.1. Session 1.3.2. Session保存到Redis中 1.3.3. 实现分布Session 1.4. 总结 1.1. 中间件原理 1.1.1. 什么是中间件 中间件是段代码用于处理请求和响应，通常多个中间件链接起来形成管道，由每个中间件自己来决定是否要调用下一个中间件。 1.1.2. 中间件执行过程 举一个示例来演示中间件的执行过程（分别有三个中间件：日志记录、权限验证和路由）：当请求进入应用程序时，执行执行日志记录的中间件，它记录请求属性并调用链中的下一个中间件权限验证，如果权限验证通过则将控制权传递给下一个中间件，不通过则设置401 HTTP代码并返回响应，响应传递给日志中间件进行返回。 1.1.3. 中间件的配置 中间件配置主要是用 Run 、 Map 和 Use 方法进行配置，三者的不同参见上篇 ASP.NET Core 运行原理剖析 ；简单的中间件可以直接使用匿名方法就可以搞定，如下代码： app.Run(async (context,next) => { await

每个大型网站都是由小变大的，在变大的过程中，几乎都需要经历单机架构、集群架构到分布式架构的演变。而伴随着业务系统架构一同演变的，还有各种外围系统和存储系统，比如关系型数据库的分库分表改造、从本地缓存到分布式缓存的过渡等。 在业务架构逐渐复杂的同时，保证系统的高性能、高可用、易扩展、可伸缩，使框架能有效地满足业务需要，是一个长远而艰巨的任务。本文介绍了五种相关的技术：分布式服务化架构、大流量的限流和削峰、分布式配置管理服务、热点数据的读写优化和数据库的分库分表。 值得注意的是，技术并不是越复杂越好，技术是为了更好地服务业务，只要能达到业务的需求，就是好的技术。简单说就是，即使你有实现复杂技术的能力，没有用户量和利润为基础，也难以落地实施。所以虽然下文中提到了一些框架，但是并不是每一种框架都需要你去亲自实践。很多时候，只是给你提供一个新的思路，一种新的方法，而至于是不是值得被实践，还需要得到业务和用户的考验。 文章目录 分布式服务化架构 集群和分布式 服务化架构，微服务和RPC 服务化架构的组成 服务的横向拆分 服务治理方案 总结 大流量的限流和削峰 分布式系统为什么要进行流量管制 限流方案 削峰方案 基于时间分片的削峰方案 基于异步调用的削峰方案 分布式配置管理服务 热点数据的读写优化 缓存技术 热卖商品的高并发读 基于Redis集群的多写多读方案

“数据不能丢，服务不能停”，可以说这句话道出了用户对数据库的核心能力的要求。然而，传统的商业数据库必须依赖高可靠的硬件才能实现数据可靠性和服务可用性。OceanBase作为一款成熟的企业级分布式数据库，基于普通PC服务器，就能够做到传统高端硬件环境下的数据可靠性和服务可用性，而且还能做得更好！跟我们一起看看OceanBase的技术秘诀吧！ Part1 前言 说到数据可靠性和服务可用性，在数据库领域真是老生常谈的话题，可以说从数据库诞生之日起就如影随形。如果要用一句话来概括数据库对数据可靠性和服务可用性的要求，可以借用OceanBase数据库创始人阳振坤老师的一句话：“数据不能丢，服务不能停”。可以说，这句话也道出了用户对数据库的一个核心能力要求：除了功能完善、使用方便之外，还要绝对安全、足够健壮。可以说，为了满足这两个看似简单的要求，在数据库领域诞生了大量的技术和论文，也让无数人绞尽了脑汁。 在传统的商业数据库产品（如Oracle、DB2）中，虽然也有一些行之有效的软件技术（如Redo Log、主从热备技术等）用来提高数据可靠性和服务可用性，但整体来说对硬件的稳定性有很强的依赖。而传统的企业级服务器（如IBM 的Mainframe、AS400、Power等）和EMC、IBM等厂商的高端存储产品，能够很好的保证硬件的稳定性，因此也就成为了Oracle为代表的传统数据库产品的理想平台

消息队列及常见消息队列介绍 一、消息队列(MQ)概述 消息队列（Message Queue），是分布式系统中重要的组件，其通用的使用场景可以简单地描述为： 当不需要立即获得结果，但是并发量又需要进行控制的时候，差不多就是需要使用消息队列的时候。 消息队列主要解决了应用耦合、异步处理、流量削锋等问题。 当前使用较多的消息队列有RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMq等，而部分数据库如Redis、Mysql以及phxsql也可实现消息队列的功能。 二、消息队列使用场景 消息队列在实际应用中包括如下四个场景： 应用耦合：多应用间通过消息队列对同一消息进行处理，避免调用接口失败导致整个过程失败； 异步处理：多应用对消息队列中同一消息进行处理，应用间并发处理消息，相比串行处理，减少处理时间； 限流削峰：广泛应用于秒杀或抢购活动中，避免流量过大导致应用系统挂掉的情况； 消息驱动的系统：系统分为消息队列、消息生产者、消息消费者，生产者负责产生消息，消费者(可能有多个)负责对消息进行处理； 下面详细介绍上述四个场景以及消息队列如何在上述四个场景中使用： 2.1 异步处理 具体场景：用户为了使用某个应用，进行注册，系统需要发送注册邮件并验证短信。对这两个操作的处理方式有两种：串行及并行。 （1）串行方式：新注册信息生成后，先发送注册邮件

设计高性能大并发WEB系统架构注意点 第01：大型架构的演进之路 第02（上）：分布式缓存 第02（下）：分布式缓存 第03：分布式消息队列 第04：分布式数据存储 第05：分布式服务框架 第06：高性能系统架构 第07：高可用系统架构 第08：系统的安全架构 第09：架构实战案例分析 ------------------------------------------------------------------------------------------------- 系统的垂直伸缩，水平伸缩 系统的性能瓶颈：分部式缓存；分布式数据存储，分布式服务架构； 强烈的好奇心，工程技术，产生价值赚钱（科学研究不同） 扎实的软件技术基础：操作系统，数据结构，设计模式，编程语言， 出色的编程能力：优秀的代码 深刻领悟主流技术产品模式； 互联网架构的关键技术：缓存，异步，分布 互联网架构的核心要素：性能，可用，安全 架构设计方案：系统，框架，数据库 架构师的成长：搞定问题的攻略 大型分布式架构 优秀架构师必备的技能： 强烈的好奇心， 敏锐的业务嗅觉，工程技术，产生价值赚钱（科学研究不同） 扎实的软件技术基础：操作系统，数据结构，数据库原理，设计模式，编程语言， 出色的编程能力：优秀的代码 深刻领悟主流技术产品模式：站在巨人的肩膀上思考； 架构知识体系和学习路径： 基础扎实：操作系统原理

本文引用自 http://www.cnblogs.com/sunddenly/p/4033574.html 引言 　　Hadoop 集群当中 N 多的配置信息如何做到全局一致并且单点修改迅速响应到整个集群？ --- 配置管理 　　Hadoop 集群中的 namonode 和 resourcemanager 的单点故障怎么解决？ --- 集群的主节点的单点故障 分布式协调技术 　　在给大家介绍ZooKeeper之前先来给大家介绍一种技术——分布式协调技术。那么什么是分布式协调技术？那么我来告诉大家，其实分布式协调技术 主要用来解决分布式环境当中多个进程之间的同步控制，让他们有序的去访问某种临界资源，防止造成"脏数据"的后果。这时，有人可能会说这个简单，写一个调 度算法就轻松解决了。说这句话的人，可能对分布式系统不是很了解，所以才会出现这种误解。如果这些进程全部是跑在一台机上的话，相对来说确实就好办了，问 题就在于他是在一个分布式的环境下，这时问题又来了，那什么是分布式呢？这个一两句话我也说不清楚，但我给大家画了一张图希望能帮助大家理解这方面的内 容，如果觉得不对尽可拍砖，来咱们看一下这张图，如图1.1所示。 　　给大家分析一下这张图，在这图中有三台机器，每台机器各跑一个应用程序。然后我们将这三台机器通过网络将其连接起来，构成一个系统来为用户提供服务，对用户来说这个系统的架构是透明的

一、分布式协调技术 在给大家介绍ZooKeeper之前先来给大家介绍一种技术——分布式协调技术。那么什么是分布式协调技术？那么我来告诉大家，其实分布式协调技术 主要用来解决分布式环境当中多个进程之间的同步控制，让他们有序的去访问某种临界资源，防止造成"脏数据"的后果。这时，有人可能会说这个简单，写一个调 度算法就轻松解决了。说这句话的人，可能对分布式系统不是很了解，所以才会出现这种误解。如果这些进程全部是跑在一台机上的话，相对来说确实就好办了，问 题就在于他是在一个分布式的环境下，这时问题又来了，那什么是分布式呢？这个一两句话我也说不清楚，但我给大家画了一张图希望能帮助大家理解这方面的内 容，如果觉得不对尽可拍砖，来咱们看一下这张图，如图1.1所示。 图 1.1 分布式系统图 给大家分析一下这张图，在这图中有三台机器，每台机器各跑一个应用程序。然后我们将这三台机器通过网络将其连接起来，构成一个系统来为用户提供服务，对用户来说这个系统的架构是透明的，他感觉不到我这个系统是一个什么样的架构。那么我们就可以把这种系统称作一个 分布式系统 。 那我们接下来再分析一下，在这个分布式系统中如何对进程进行调度，我假设在第一台机器上挂载了一个资源，然后这三个物理分布的进程都要竞争这个资源，但我们又不希望他们同时进行访问，这时候我们就需要一个 协调器 ，来让他们有序的来访问这个资源

一、分布式协调技术 在给大家介绍ZooKeeper之前先来给大家介绍一种技术——分布式协调技术。那么什么是分布式协调技术？那么我来告诉大家，其实分布式协调技术主要用来解决分布式环境当中多个进程之间的同步控制，让他们有序的去访问某种临界资源，防止造成"脏数据"的后果。这时，有人可能会说这个简单，写一个调度算法就轻松解决了。说这句话的人，可能对分布式系统不是很了解，所以才会出现这种误解。如果这些进程全部是跑在一台机上的话，相对来说确实就好办了，问题就在于他是在一个分布式的环境下，这时问题又来了，那什么是分布式呢？这个一两句话我也说不清楚，但我给大家画了一张图希望能帮助大家理解这方面的内容，如果觉得不对尽可拍砖，来咱们看一下这张图，如图1.1所示。 图 1.1 分布式系统图 给大家分析一下这张图，在这图中有三台机器，每台机器各跑一个应用程序。然后我们将这三台机器通过网络将其连接起来，构成一个系统来为用户提供服务，对用户来说这个系统的架构是透明的，他感觉不到我这个系统是一个什么样的架构。那么我们就可以把这种系统称作一个 分布式系统 。 那我们接下来再分析一下，在这个分布式系统中如何对进程进行调度，我假设在第一台机器上挂载了一个资源，然后这三个物理分布的进程都要竞争这个资源，但我们又不希望他们同时进行访问，这时候我们就需要一个 协调器 ，来让他们有序的来访问这个资源

现在先抛出问题，假设有一个主数据中心在北京M，然后有成都A，上海B两个地方数据中心，现在的问题是，假设成都上海各自的数据中心有记录变更，需要先同步到主数据中心，主数据中心更新完成之后，在把最新的数据分发到上海，成都的地方数据中心A，地方数据中心更新数据，保持和主数据中心一致性（数据库结构完全一致）。数据更新的消息是通过一台中心的MQ进行转发。 先把问题简单化处理，假设A增加一条记录Message_A，发送到M，B增加一条记录 MESSAGE_B发送到M，都是通过MQ服务器进行转发，那么M系统接收到条消息，增加两条数据，那么M在把增加的消息群发给A，B，A和B找到自己缺失的数据，更新数据库。这样就完成了一个数据的同步。 从正常情况下来看，都没有问题，逻辑完全合理，但是请考虑以下三个问题 1 如何保证A->M的消息，M一定接收到了，同样，如何保证M->A的消息，M一定接收到了 2 如果数据需要一致性更新，比如A发送了三条消息给M，M要么全部保存，要么全部不保存，不能够只保存其中的几条记录。我们假设更新的数据是一条条发送的。 3 假设同时A发送了多条更新请求，如何保证顺序性要求？ 这两个问题就是分布式环境下数据一致性的问题 对于第一个问题，比较好解决，我们先看看一个tcp/ip协议链接建立的过程 我们的思路可以从这个上面出发，在简化一下，就一个请求，一个应答。 简单的通信模型是这样的 A