分布式技术

分布式网络存储技术是将数据分散地存储于多台独立的机器设备上。分布式网络存储系统采用可扩展的系统结构，利用多台存储服务器分担存储负荷，利用位置服务器定位存储信息，不但解决了传统集中式存储系统中单存储服务器的瓶颈问题，还提高了系统的可靠性、可用性和扩展性。 php分布式是指多台服务器处理不同的工作，指的是业务上的一般，比如多台服务器有的处理日志分布到一些服务器，有的处理下单，分布到一些服务器。 框架作为协同开发规范和开发效率的保证，不得不被引入到日常开发中，可一旦加上了框架这层封装，势必影响php接口的整体性能。 基于php7+swoole的php代码的性能已经超过了静态编译的go语言。 当下流行的php框架laravel，确实解决了很多规范和开发效率问题；但是臃肿的架构和用php去实现的封装，让他的性能表现不佳。 针对这种情况，本架构选择c扩展框架phalcon作为开发框架，让框架带来的性能损耗，降到最小。 使用Web集群方式部署之后，首要调整的就是用户状态信息与附件信息。用户状态不能再保存到Session中，缓存也不能用本地Web服务器的文件缓存，以及附件，也不能保存在Web服务器上了。 因为要保证集群里面的各个Web服务器，状态完全一致。因此，需要将用户状态、缓存等保存到专用的缓存服务器，比如Memcache。附件需要保存到云存储中。 Web负载均衡 Web负载均衡（Load

https://segmentfault.com/a/1190000018626163#articleHeader18 1. 概述 本文以淘宝作为例子，介绍从一百个并发到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知，文章最后汇总了一些架构设计的原则。 2. 基本概念 在介绍架构之前，为了避免部分读者对架构设计中的一些概念不了解，下面对几个最基础的概念进行介绍： 分布式 系统中的多个模块在不同服务器上部署，即可称为分布式系统，如Tomcat和数据库分别部署在不同的服务器上，或两个相同功能的Tomcat分别部署在不同服务器上 高可用 系统中部分节点失效时，其他节点能够接替它继续提供服务，则可认为系统具有高可用性 集群 一个特定领域的软件部署在多台服务器上并作为一个整体提供一类服务，这个整体称为集群。如Zookeeper中的Master和Slave分别部署在多台服务器上，共同组成一个整体提供集中配置服务。在常见的集群中，客户端往往能够连接任意一个节点获得服务，并且当集群中一个节点掉线时，其他节点往往能够自动的接替它继续提供服务，这时候说明集群具有高可用性 负载均衡 请求发送到系统时，通过某些方式把请求均匀分发到多个节点上，使系统中每个节点能够均匀的处理请求负载，则可认为系统是负载均衡的 正向代理和反向代理

Google学术论文，这是众多分布式文件系统的起源 ================================== Google File System（大规模分散文件系统） MapReduce （大规模分散FrameWork） BigTable（大规模分散数据库） Chubby（分散锁服务） 一般你搜索Google_三大论文中文版(Bigtable、 GFS、 Google MapReduce)就有了。 做个中文版下载源：http://dl.iteye.com/topics/download/38db9a29-3e17-3dce-bc93-df9286081126 做个原版地址链接： http://labs.google.com/papers/gfs.html http://labs.google.com/papers/bigtable.html http://labs.google.com/papers/mapreduce.html GFS（Google File System） -------------------------------------- Google公司为了满足本公司需求而开发的基于Linux的专有分布式文件系统。。尽管Google公布了该系统的一些技术细节，但Google并没有将该系统的软件部分作为开源软件发布。 下面分布式文件系统都是类

一、微服务交互模式 1.1、同步调用 特点： 请求服务方调用响应服务方，请求方阻塞等待响应处理结果，一直等待到超时或成功。 适用场景： 大规模，高并发的短小操作，不适用后端负载较高的场景。如：JDBC实现为BIO同步阻塞 1.2、异步调用 特点： 请求服务调用响应服务，响应服务受理成功后，请求服务继续其他操作，当响应服务操作成功后请求服务做后续处理操作 使用场景： 非核心链路处理，耗时长，对实时要求不高。 1.3、消息队列异步处理 特点： 发送者发送消息给接收者，发送者不等待接收者返回结果。实现了服务之间的解耦，一般应用于非核心链路负载较高环节。 使用场景： 用户支付成功后采用消息方式异步处理物流信息。 1.4、同步与异步选择 同步与异步选择原则： 1、尽量使用异步代替同步操作： 从实际业务出发，将耗时操作放在异步处理 2、能用同步解决的问题不用异步： 从技术架构出发没有性能问题使用同步操作 二、交互模式解决方案 2.1、同步调用解决方案 同步状态下服务会返回两种状态的数据 两种状态接口：成功，失败 三种状态接口：成功，失败，处理中 2.1.1、两状态的同步接口：成功，失败 1、服务调用同步接口时（返回失败时）： 调用方发起重试再次处理（重试需要进行幂等性处理） 2、服务之间调用时（返回失败时）： 使用快速失败策略：针对这个超时服务快速返回失败 调用方调用被调用方的冲正接口

常见的 分布式文件系统 有， GFS 、 HDFS 、 Lustre 、 Ceph 、 GridFS 、 mogileFS 、 TFS 、 FastDFS 等。各自适用于不同的领域。它们都不是系统级的 分布式 文件系统，而是应用级的分布式文件存 储服务。 Google 学术论文，这是众多分布式文件系统的起源 ================================== Google File System（大规模分散文件系统） MapReduce （大规模分散FrameWork） BigTable （大规模分散数据库） Chubby（分散锁服务） 一般你搜索Google_三大论文中文版( Bigtable 、 GFS、 Google MapReduce)就有了。 做个中文版下载源：http://dl.iteye.com/topics/download/38db9a29-3e17-3dce-bc93-df9286081126 做个原版地址链接： http://labs.google.com/papers/gfs.html http://labs.google.com/papers/bigtable.html http://labs.google.com/papers/mapreduce.html GFS（Google File System） ----------------

课程介绍: 分布式事务是一个绕不过去的挑战！微服务架构本质上就是分布式服务化架构，微服务架构的流行，让分布式事务问题日益突出！尤其是在订单业务、资金业务等系统核心业务流程中，一定要有可靠的分布式事务解决方案来保证业务数据的可靠性和准确性。 为了解决大家在实施分布式服务化架构过程中关于分布式事务问题的困扰，本教程将基于支付系统真实业务中的经典场景来对“可靠消息的最终一致性方案”、“TCC两阶段型方案”和“最大努力通知型方案”这3种柔性事务解决方案进行具体设计实现和详细讲解。 本教程提供的分布式事务解决方案的设计思路在所有微服务架构项目中都适用，与编程语言无关，教程中会重点讲解方案的设计思路。 教程中的样例项目基于龙果学院开源的微支付系统进行实现，使用Dubbo作为服务化框架，教程中所实现的分布式事务解决方案在Java体系中的微服务架构系统都能通用，与具体的开发框架无关。 教程样例项目中用到的技术及相应的环境： Dubbo、Spring、SpringMVC、MyBatis、Druid、JDK7（或JDK8）、MySQL5.6、Tomcat 课程大纲: 第1节课程介绍 第2节解决方案的效果演示（结合支付系统真实应用场景） 第3节常用的分布式事务解决方案介绍 [免费观看] 47分钟 第4节消息发送一致性（可靠消息的前提保障）20分钟 第5节消息发送一致性的异常流程处理16分钟

为什么要使用分布式Session Web应用在单机部署的情况下，Session是被单个应用服务器存储管理的，由于只有一个应用服务器，用户的所有请求都是通过它进行响应处理的，所以能够很容易实现会话跟踪和保持。随着业务量的增长，系统架构需要做出调整以适应发展的需要，可能会使用分布式架构或微服务架构，无论使用哪种架构方式，应用系统单机部署的模式已经不能满足需求，所以会将应用系统部署到多台应用服务器上，用户的请求也会通过负载均衡转发到某个具体应用服务器上执行，可能会出现在A1系统登录后创建并保存Session，再次发起请求，请求被转发到A2系统上显示未登录的情况，此时单机部署模式下的Session机制已不能满足要求。所以，在分布式架构或微服务架构下，必须保证一个应用服务器上保存Session后，其它应用服务器可以同步或共享这个Session。 分布式session管理实现方案 分布式Session有如下几种实现方式。 1.Session复制 在支持Session复制的Web服务器上，通过修改Web服务器的配置，可以实现将Session同步到其它Web服务器上，达到每个Web服务器上都保存一致的Session。 优点：代码上不需要做支持和修改。 缺点：需要依赖支持的Web服务器，一旦更换成不支持的Web服务器就不能使用了，在数据量很大的情况下不仅占用网络资源，而且会导致延迟。 适用场景

最近，在工作中遇到一个问题，问题描述：一个用户在登录成功以后会把用户信息存储在session当中，这时session所在服务器为server1，那么用户在session失效之前如果再次使用app，那么可能会被路由到server2，这时问题来了，server没有该用户的session，所以需要用户重新登录，这时的用户体验会非常不好，所以我们想如何实现多台server之间共享session，让用户状态得以保存。 当然业界已经有很多成熟的解决方案，我罗列如下： 1.服务器实现的session复制或session共享，这类型的共享session是和服务器紧密相关的，比如webSphere或JBOSS在搭建集群时候可以配置实现session复制或session共享，但是这种方式有一个致命的缺点，就是不好扩展和移植，比如我们更换服务器，那么就要修改服务器配置。 2.利用成熟的技术做session复制，比如12306使用的gemfire，比如常见的内存数据库如redis或memorycache，这类方案虽然比较普适，但是严重依赖于第三方，这样当第三方服务器出现问题的时候，那么将是应用的灾难。 3.将session维护在客户端，很容易想到就是利用cookie，但是客户端存在风险，数据不安全，而且可以存放的数据量比较小，所以将session维护在客户端还要对session中的信息加密。

美团外卖从2013年9月成交第一单以来，已走过了三个年头。期间，业务飞速发展，美团外卖由日均几单发展为日均500万单（9月11日已突破600万）的大型O2O互联网外卖服务平台。平台支持的品类也由最初外卖单品拓展为全品类。 随着订单量的增长、业务复杂度的提升，外卖订单系统也在不断演变进化，从早期一个订单业务模块到现在分布式可扩展的高性能、高可用、高稳定订单系统。整个发展过程中，订单系统经历了几个明显的阶段，下面本篇文章将为大家介绍一下订单系统的演进过程，重点关注各阶段的业务特征、挑战及应对之道。 为方便大家更好地了解整个演进过程，我们首先看一下外卖业务。 外卖订单业务 外卖订单业务是一个需要即时送的业务，对实时性要求很高。从用户订餐到最终送达用户，一般在1小时内。如果最终送达用户时间变长，会带来槽糕的用户体验。在1小时内，订单会快速经过多个阶段，直到最终送达用户。各个阶段需要紧密配合，确保订单顺利完成。 下图是一个用户视角的订单流程图： 从普通用户的角度来看，一个外卖订单从下单后，会经历支付、商家接单、配送、用户收货、售后及订单完成多个阶段。以技术的视角来分解的话，每个阶段依赖于多个子服务来共同完成，比如下单会依赖于购物车、订单预览、确认订单服务，这些子服务又会依赖于底层基础系统来完成其功能。 外卖业务另一个重要特征是一天内订单量会规律变化，订单会集中在中午、晚上两个“饭点”附近

https://blog.csdn.net/ityouknow/article/details/82393102 引言：继上篇《几种分布式调用链监控组件的实践与比较（一）实践》后，本篇将会讲下几种APM选型的比较与性能测试。 1. 前文回顾 上一篇文章主要讲了三种分布式调用链监控组件的实践。问题的背景由微服务架构展开，微服务的好处已经不用多说，而微服务的多了之后，千头万绪，下面这张图经常被用到。 系统的复杂度因此提升。系统越复杂，越难解决问题，例如系统失败或者性能问题。在三层架构中找到解决方案还不是太难，仅仅需要分析3个组件比如web服务器，应用服务器和数据库，而服务器数量也不多。但是，如果问题发生在n层架构中，就需要调查大量的组件和服务器。另一个问题是仅仅分析单个组件很难看到大局;当发生一个低可见度的问题时，系统复杂度越高，就需要更长的时间来查找原因。最糟糕的是，某些情况下我们甚至可能无法查找出来。 上面其实已经提到存在的故障定位问题，基于微服务体系之下构建的业务系统存在的问题基本上分为三类： 故障定位难，一个简单操作，其背后可能是由十几个微服务共同完成的，这些微服务也由不同的团队去负责。一旦出现问题，最坏情况下我们也许需要这十几个团队一起来解决问题。 链路梳理难，应用没有形成应用拓扑，不知道自己的服务下游会影响其他哪些人。 资源浪费多，容量预估难。对于一些服务