分布式开发

Redis在豌豆荚的使用历程——单实例==》多实例，业务代码中做sharding==》单个Twemproxy==》多个Twemproxy==》Codis，豌豆荚自己开发的分布式Redis服务。在大规模的Redis使用过程中，他们发现Redis受限于多个方面：单机内存有限、带宽压力、单点问题、不能动态扩容以及磁盘损坏时的数据抢救。 Redis通常有3个使用途径：客户端静态分片，一致性哈希；通过Proxy分片，即Twemproxy；还有就是官方的Redis Cluster，但至今无一个新版本。随后刘奇更详细的分析了为什么不使用Twemproxy和Redis Cluster： Twemproxy：最大的痛点是无法平滑的扩容或者缩容，甚至修改配置都需要重启服务；其次，不可运维，甚至没有Dashboard。 Redis Cluster（官方）：无中心化设计，程序难以编写；代码有点吓人，clusterProcessPacket函数有426行，人脑难以处理所有的状态切换；迟迟没有正式版本，等了4年之久；目前还缺乏最佳实践，没有人编写Redis Cluster的若干条注意事项；整个系统高度耦合，升级困难。 虽然我们有众多的选择，比如 Tair 、 Couchbase 等，但是如果你需要更复杂和优秀的数据结构， Redis 可称为不二之选。基于这个原因，在 Redis 之上，豌豆荚设计了 Codis

某厂面试归来，发现自己落伍了！>>> RPC 简介 RPC（Remote Procedure Call）——远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的细节的技术。 通过RPC我们可以充分利用非共享内存的多处理器环境（例如通过局域网连接得多台工作站）,这样可以简便地将你的应用分布在多台工作站上，应用程序就像运行在一个多处理器的计算机上一样。你可以方便的实现过程代码共享，提高系统资源的利用率，也可以将以大量数值处理的操作放在处理能力较强的系统上运行，从而减轻前端机的负担。 在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。 RPC 的主要目的是为组件提供一种相互通信的方式，使这些组件之间能够相互发出请求并传递这些请求的结果。 RPC 调用过程 客户机对服务器的一次RPC调用,其内部操作大致有如下十步： 1.调用客户端句柄；执行传送参数 2.调用本地系统内核发送网络消息 3.消息传送到远程主机 4.服务器句柄得到消息并取得参数 5.执行远程过程 6.执行的过程将结果返回服务器句柄 7.服务器句柄返回结果，调用远程系统内核 8.消息传回本地主机 9.客户句柄由内核接收消息 10.客户接收句柄返回的数据 RPC 的应用场景 RPC 在分布式系统中的系统环境建设和应用程序设计中有着广泛韵应用

以下是消息队列以下的大纲，本文主要介绍消息队列概述，消息队列应用场景和消息中间件示例（电商，日志系统）。 本次分享大纲 消息队列概述 消息队列应用场景 消息中间件示例 JMS消息服务 常用消息队列 参考（推荐）资料 本次分享总结 一、消息队列概述 消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息，流量削锋等问题。实现高性能，高可用，可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。 目前在生产环境，使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ等。 二、消息队列应用场景 以下介绍消息队列在实际应用中常用的使用场景。异步处理，应用解耦，流量削锋和消息通讯四个场景。 2.1异步处理 场景说明：用户注册后，需要发注册邮件和注册短信。传统的做法有两种1.串行的方式；2.并行方式。 （1）串行方式：将注册信息写入数据库成功后，发送注册邮件，再发送注册短信。以上三个任务全部完成后，返回给客户端。（架构KKQ：466097527，欢迎加入） （2）并行方式：将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信。以上三个任务完成后，返回给客户端。与串行的差别是，并行的方式可以提高处理的时间。 假设三个业务节点每个使用50毫秒钟，不考虑网络等其他开销，则串行方式的时间是150毫秒

本文是大型网站架构系列：消息队列（二），主要分享JMS消息服务，常用消息中间件（Active MQ，Rabbit MQ，Zero MQ，Kafka）。【第二篇的内容大部分为网络资源的整理和汇总，供大家学习总结使用，最后有文章来源】 本次分享大纲 消息队列概述（见第一篇： 大型网站架构系列：分布式消息队列（一） ） 消息队列应用场景（见第一篇： 大型网站架构系列：分布式消息队列（一） ） 消息中间件示例（见第一篇： 大型网站架构系列：分布式消息队列（一） ） JMS消息服务 常用消息队列 参考（推荐）资料 本次分享总结 四、JMS消息服务 讲消息队列就不得不提JMS 。JMS（JAVA Message Service,java消息服务）API是一个消息服务的标准/规范，允许应用程序组件基于JavaEE平台创建、发送、接收和读取消息。它使分布式通信耦合度更低，消息服务更加可靠以及异步性。 在EJB架构中，有消息bean可以无缝的与JM消息服务集成。在J2EE架构模式中，有消息服务者模式，用于实现消息与应用直接的解耦。 4.1消息模型 在JMS标准中，有两种消息模型P2P（Point to Point）,Publish/Subscribe(Pub/Sub)。 4.1.1 P2P模式 P2P模式包含三个角色：消息队列（Queue），发送者(Sender)，接收者(Receiver)

视图可以看作定义在SQL Server上的虚拟表.视图正如其名字的含义一样，是另一种查看数据的入口.常规视图本身并不存储实际的数据，而仅仅存储一个Select语句和所涉及表的metadata. 视图简单的理解如下: 通过视图，客户端不再需要知道底层table的表结构及其之间的关系。视图提供了一个统一访问数据的接口。 为什么要使用视图(View) 从而我们不难发现，使用视图将会得到如下好处: 视图隐藏了底层的表结构，简化了数据访问操作 因为隐藏了底层的表结构，所以大大加强了安全性，用户只能看到视图提供的数据 使用视图，方便了权限管理，让用户对视图有权限而不是对底层表有权限进一步加强了安全性 视图提供了一个用户访问的接口，当底层表改变后，改变视图的语句来进行适应，使已经建立在这个视图上客户端程序不受影响 视图(View)的分类 视图在SQL中可以分为三类 普通视图(Regular View) 索引视图(Indexed View) 分割视图(Partitioned View) 下面从这几种视图类型来谈视图 普通视图(Rugular View) 普通视图由一个Select语句所定义，视图仅仅包含其定义和被引用表的metadata.并不实际存储数据。MSDN中创建视图的模版如下: CREATE VIEW [ schema_name . ] view_name [ (column [ ,..

分布式消息队列 kafka介绍 基本架构 Kafka是开源的分布式消息队列，能够轻松实现高吞吐、可扩展、高可用，并且部署简单快速、开发接口丰富。 kafka分布式消息队列的作用： 解耦：将消息生产阶段和处理阶段拆分开，两个阶段互相独立各自实现自己的处理逻辑，通过kafka提供的消息写入和消费接口实现对消息的连接处理。降低开发复杂度，提高系统稳定性。 高吞吐量：kafka通过顺序读写磁盘提供可以和内存随机读写相匹敌的读写速度，灵活的客户端API设计，利用Linux操作系统提供的“零拷贝”特性减少消息网络传输时间，提供端到端的消息压缩传输，对同一主题下的消息采用分区存储，kafka通过诸多良好的特性利用廉价的机器就可以轻松实现高吞吐率。 高容错、高可用：kafka允许用户对分区配置多副本，kafka将副本均匀分配到各个broker存储，保证同一个分区的副本不会再同一台机器上存储（集群模式下），多副本之间采用Leader-Follower机制同步消息，只有Leader对外提供读写服务，当Leader以外失败、Broker进程关闭、服务宕机等情况导致数据不可用时，kafka会从Follwer中选择一个Leader继续提供读写服务。 可扩展：理论上kafka的性能随着Broker的增多而增加，增加一个Broker只需要为新增加的Broker设置一个唯一编号，编写好配置文件后

alibaba有好几个分布式框架，主要有：进行远程调用(类似于RMI的这种远程调用)的(dubbo、hsf)，jms消息服务(napoli、notify)，KV数据库(tair)等。这个框架/工具/产品在实现的时候，都考虑到了容灾，扩展，负载均衡，于是出现一个配置中心(ConfigServer)的东西来解决这些问题。 基本原理如图： 在我们的系统中，经常会有一些跨系统的调用，如在A系统中要调用B系统的一个服务，我们可能会使用RMI直接来进行，B系统发布一个RMI接口服务，然后A系统就来通过RMI调用这个接口，为了解决容灾，扩展，负载均衡的问题，我们可能会想很多办法，alibaba的这个办法感觉不错。 本文只说dubbo，原理如下： ConfigServer 配置中心，和每个Server/Client之间会作一个实时的心跳检测（因为它们都是建立的Socket长连接），比如几秒钟检测一次。收集每个Server提供的服务的信息，每个Client的信息，整理出一个服务列表，如： serviceName serverAddressList clientAddressList UserService 192.168.0.1，192.168.0.2，192.168.0.3，192.168.0.4 172.16.0.1，172.16.0.2 ProductService 192.168.0.3

整理了一些Java方面的架构、面试资料（微服务、集群、分布式、中间件等），有需要的小伙伴可以关注公众号【程序员内点事】，无套路自行领取 更多优选 一口气说出 9种 分布式ID生成方式，面试官有点懵了 面试总被问分库分表怎么办？你可以这样怼他 3万字总结，Mysql优化之精髓 技术部突然宣布：JAVA开发人员全部要会接口自动化测试框架 9种分布式ID生成之美团（Leaf）实战 絮絮叨叨 还记得刚入行开始写Java时，接触的第一个项目是国家电网的一个业务系统，这个系统据说投资了5亿人民币进行研发，鼎盛时期研发人员一度达到过500人。项目采用当时最流行的ssh（Struts+Spring+Hibernate）框架，典型的三层架构（controller - > service -> dao）简单又粗暴，所有人写的代码都放在一个大工程里，项目文件大小达到几百M，解决代码冲突是当时最大的工作量。 然而戏剧性的是，交测当天五人同时上线，项目崩 崩 崩溃了。。。 哎！你永远想象不到甲方愤怒的样子，项目组每个人的祖宗都被问候到了。 说了一些没用的，脑子里总想起这个事，不说不痛快，大家姑且就当笑话听吧，下边我们进入正题 引言 前两天有个学弟公众号留言，说让讲讲分布式事务，面试就挂在这个问题上。时下随着微服务架构体系的流行，面试的题目也都慢慢开始升级，不再是早些年单纯的问点SSH框架知识、数据结构了。

微服务来源 单体应用 微服务是相对于单体应用的，在介绍微服务之前，先简单介绍一下单体应用：通常是由三个重要部分组成：客户端界面（由HTML、JavaScript组成）、数据库（由许多的表组件构成一个通用的、相互关联的数据管理系统）、服务端应用。服务端应用处理客户端的HTTP请求、执行逻辑、检索并更新数据库中的数据、然后将处理后的数据返回给客户端。 一个单体应用被构建成一个系统时，业务中所有请求都要在单一的进程中处理完成，当访问量很高情况下服务器压力是很大的。当然可以水平扩展，利用负载均衡将实例布署到多台服务器中。 单体架构的缺点 [ ] 开发效率低 [ ] 代码维护难 [ ] 部署不灵活 [ ] 稳定性不高 [ ] 扩展性不高 云时代 在此之前单体应用也是很成功的，但是随着云时代的到来，单体应用就显得有些不妥了，特别是应用程序发布到云端的时候，一个功能的变更，需要统一的编译和发布。这样的架构模式很难使得一个模块的变更不影响到其他模块，而且在扩展方面也只能进行整体的扩展，不能根据正在运行的部分进行扩展。 微服务架构风格 云时代单体应用的尴尬导致了微服务架构风格的出现：以服务构建应用。 一个系统由多个服务组成，各服务可以被独立布署、独立扩展，每个服务也都提供了清晰的模块边界，甚至不同的服务都可以使用不同的编程语言来实现，也可以由不同的团队进行管理。 微服务介绍

摘自： https://www.cnblogs.com/yangyuanhu/p/12439106.html Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。 2 | 0 什么是RPC RPC全称(Remote Procedure Call)远程过程调用 过程指的是某个代码片段的执行,远程调用则意味着我们可以在其他进程,甚至其他机器上去调用这段代码,当然也能获取到其执行后的返回值,按照这个定义,我们请求某个http地址得到相应数据其实也算一次RPC,但是这样的方式太过麻烦,(数据要先打包成http请求格式,在调用相关的请求库,拿到的结果也是文本格式的需要在进行转换),执行效率,和开发效率相比RPC则低一些; 我们需要一种更简单的方式来完成分布式开发中的RPC环节,这也是Dubbo的核心所在,有多简单呢? 调用远程服务器上的某个服务时就像是调用本地的某个方法一样简单,就像下面这样 2 | 1 为什么需要rpc RPC是用来实现分布式构架的基石,分布式构架将同一个系统中的不同模块拆分到不同的子系统中,而子系统又分布在不同的服务器上,这时就需要RPC在来完成子系统之间的相互访问; 可以这么说分布式少不了RPC,RPC也要在分布式系统中才能发挥其核心价值; 2 | 2 rpc的实现原理