分布式技术

1 session存储策略 存储，即在后台使用session的setAttribute,getAttribute等方法时，这些内部存放的数据最终存储至什么位置。比如在默认的tomcat实现中，相应的数据即存储在内存中，并在停止之后会序列化至磁盘中。 可以使用内存存储和第三方存储，如redis。对于集群式的session存储，那么肯定会使用第三方存储的实现。 在spring-session中，对session存储单独作了一个定义，但定义上基本保证与http session一致，主要的目的在于它可以支持在非http的环境中模拟使用。因此不直接使用http session接口。 先看定义： public interface Session { /** 获取惟一的id,可以理解为即将每个session当作一个实体对象 */ String getId(); <T> T getAttribute(String attributeName); Set<String> getAttributeNames(); void setAttribute(String attributeName, Object attributeValue); void removeAttribute(String attributeName); } 从这个定义来看，如果要使用httpSession

1 session存储策略 存储，即在后台使用session的setAttribute,getAttribute等方法时，这些内部存放的数据最终存储至什么位置。比如在默认的tomcat实现中，相应的数据即存储在内存中，并在停止之后会序列化至磁盘中。 可以使用内存存储和第三方存储，如redis。对于集群式的session存储，那么肯定会使用第三方存储的实现。 在spring-session中，对session存储单独作了一个定义，但定义上基本保证与http session一致，主要的目的在于它可以支持在非http的环境中模拟使用。因此不直接使用http session接口。 先看定义： public interface Session { /** 获取惟一的id,可以理解为即将每个session当作一个实体对象 */ String getId(); <T> T getAttribute(String attributeName); Set<String> getAttributeNames(); void setAttribute(String attributeName, Object attributeValue); void removeAttribute(String attributeName); } 从这个定义来看，如果要使用httpSession

转载自 https://www.sohu.com/a/285175900_132276 开源展示了人类共同协作，成果分享的魅力，每一次技术发展都是站在巨人的肩膀上，技术诸多创新和发展往往就是基于开源发展起来的，没有任何一家网络公司可以不使用开源技术，仅靠自身技术而发展起来。阿里巴巴各个团队都是发自内心地将踩过的坑和总结的经验融入到开源项目中，供业界所有人使用，希望帮助他人解决问题。 云栖社区特在2018年年末，将阿里巴巴的一些重要的开源项目进行整理，希望对大家有所帮助。（以下项目排名不分先后） 这些优质的开源项目即将成立便于开发者交流的讨论钉钉群。社区将不断更新，欢迎大家加入讨论。 前端 1.数据驱动的高交互可视化图形语法 AntV - G2 G2 是一套基于可视化编码的图形语法，以数据驱动，具有高度的易用性和扩展性，用户无需关注各种繁琐的实现细节，一条语句即可构建出各种各样的可交互的统计图表。 同时，G2 也是 AntV 最重要的组成，始于《The Grammar of Graphics》一书描述的视觉编码语法系统（这也是 G2 项目命名的由来）。 项目地址：https://github.com/antvis/g2 2.企业级中后台 UI 解决方案 Fusion Design Fusion Design 是一种旨在提升设计与开发之间 UI 构建效率的工作方式。通过建设基于 DPL

Hadoop与Spark比较 https://www.cnblogs.com/charlesblc/p/6206198.html 感觉自己落下好多东西没有学习 先看这篇文章：http://www.huochai.mobi/p/d/3967708/?share_tid=86bc0ba46c64&fmid=0 直接比较Hadoop和Spark有难度，因为它们处理的许多任务都一样，但是在一些方面又并不相互重叠。 比如说，Spark没有文件管理功能，因而必须依赖Hadoop分布式文件系统(HDFS)或另外某种解决方案。 Hadoop框架的主要模块包括如下： Hadoop Common Hadoop分布式文件系统(HDFS) Hadoop YARN Hadoop MapReduce 虽然上述四个模块构成了Hadoop的核心，不过还有其他几个模块。这些模块包括：Ambari、Avro、Cassandra、Hive、 Pig、Oozie、Flume和Sqoop，它们进一步增强和扩展了Hadoop的功能。 Spark确实速度很快(最多比Hadoop MapReduce快100倍)。Spark还可以执行批量处理，然而它真正擅长的是处理流工作负载、交互式查询和机器学习。 相比MapReduce基于磁盘的批量处理引擎，Spark赖以成名之处是其数据实时处理功能。Spark与Hadoop及其模块兼容

hadoop学习笔记：hadoop文件系统浅析 https://www.cnblogs.com/sharpxiajun/archive/2013/06/15/3137765.html 1.什么是分布式文件系统？ 管理网络中跨多台计算机存储的文件系统称为分布式文件系统。 2.为什么需要分布式文件系统了？ 原因很简单，当数据集的大小超过一台独立物理计算机的存储能力时候，就有必要对它进行分区（partition）并存储到若干台单独计算机上。 3.分布式系统比传统的文件的系统更加复杂 因为分布式文件系统架构在网络之上，因此分布式系统引入了网络编程的复杂性，所以分布式文件系统比普通文件系统更加复杂。 4.Hadoop 的文件系统 很多童鞋会把hdfs等价于hadoop的文件系统，其实hadoop是一个综合文件系统抽象，而hdfs是hadoop旗舰级文件系统，hadoop除了hdfs还能集成其他文件系统。Hadoop的这个特点充分体现了hadoop的优良的可扩展性。 在hadoop里，hadoop定义了一个抽象的文件系统的概念，具体就是hadoop里面定义了一个java的抽象类：org.apache.hadoop.fs.FileSystm，这个抽象类用来定义hadoop中的一个文件系统接口，只要某个文件系统实现了这个接口，那么它就可以作为hadoop支持的文件系统

#0 系列目录# 分布式设计与开发 CAP原理和最终一致性(Eventually Consistency) 分布式算法 [分布式Paxos算法] 分布式一致性Hash算法 轮循算法（Round Robin） Hash求余算法（Hash） 最少连接算法（Least Connection） 响应速度算法（Response Time） 加权算法（Weighted） 分布式消息 分布式发布订阅消息系统Kafka架构设计 分布式缓存 Redis 分布式 Memcached 分布式 分布式存储 分布式事务 #1 分布式介绍# 分布式可繁也可以简，最简单的分布式就是大家最常用的， 在负载均衡服务器后加一堆web服务器，然后在上面搞一个缓存服务器来保存临时状态 ，后面共享一个数据库， 其实很多号称分布式专家的人也就停留于此 ，大致结构如下图所示： 这种环境下 真正进行分布式的只是web server而已 ，并且web server之间没有任何联系，所以结构和实现都非常简单。 有些情况下，对分布式的需求就没这么简单，在每个环节上都有分布式的需求，比如Load Balance、DB、Cache和文件等等，并且当分布式节点之间有关联时，还得考虑之间的通讯，另外，节点非常多的时候，得有监控和管理来支撑。这样看起来， 分布式是一个非常庞大的体系 ，只不过你 可以根据具体需求进行适当地裁剪

摘抄并学习 1. 微服务的发展 　　微服务倡导将复杂的单体应用拆分成若干个功能简单、松耦合的服务，这样可以降低开发难度、增强扩展性。便于敏捷开发。当前微服务的开发框架非常多，比较著名的有 Dubbo、SpringCloud、thrift、grpc 等。 2. 微服务落地存在的问题 　　虽然现在微服务如火如荼，但对其实践仍处于探索阶段。很多中小型互联网公司鉴于经验技术实力等问题，微服务落地比较困难。主要有以下几个方面： 　　1）单体应用拆分为分布式系统后，进程间的通讯机制和故障处理措施变得更加复杂。 　　2）系统微服务化后，一个看似简单的功能，内部可能需要调用多个服务并操作多个数据库实现，服务调用的分布式事务问题非常突出。 　　3）微服务数量众多，其测试、部署、监控等都变得更加困难 　　随着 RPC（远程过程调用 Remote Procedure Call） 框架的成熟，第一个问题已经逐渐得到解决。例如 dubbo 可以支持多种通讯协议，springcloud 可以非常好的支持 restful 调用。对于第二个问题，现在还没有通用方案很好的解决微服务产生的事务问题。分布式事务已经成为微服务落地最大的阻碍，也是最具挑战性的一个技术难题。 　　以下介绍分布式事务的各种解决方案，重点解读阿里巴巴提出的分布式事务解决方案 —— GTS。 3. SOA分布式事务解决方案 3.1 基于 XA

1、I/O优化 1、增加缓存，减少磁盘的访问次数。 2、优化磁盘的管理系统，设计最优的磁盘方式策略，以及磁盘的寻址策略，这是在底层操作系统层面考虑的。 3、设计合理的磁盘存储数据块，以及访问这些数据库的策略，这是在应用层面考虑的。例如，我们可以给存放的数据设计索引，通过寻址索引来加快和减少磁盘的访问量，还可以采用异步和非阻塞的方式加快磁盘的访问速度。 4、应用合理的RAID策略提升磁盘I/O。 2、Web前端调优 1、减少网络交互的次数（多次请求合并） 2、减少网络传输数据量的大小(压缩) 3、尽量减少编码（尽量提前将字符转化为字节，或者减少从字符到字节的转化过程。） 4、使用浏览器缓存 5、减少Cookie传输 6、合理布局页面 7、使用页面压缩 8、延迟加载页面 9、CSS在最上面，JS在最下面 10、CDN 11、反向代理 12、页面静态化 13、异地部署 3、服务降级（自动优雅降级） 拒绝服务和关闭服务 4、幂等性设计 有些服务天然具有幂等性，比如讲用户性别设置为男性，不管设置多少次，结果都一样。但是对转账交易等操作，问题就会比较复杂，需要通过交易编号等信息进行服务调用有效性校验，只有有效的操作才能继续执行。 （注：幂等性是系统的接口对外一种承诺(而不是实现), 承诺只要调用接口成功, 外部多次调用对系统的影响是一致的. 声明为幂等的接口会认为外部调用失败是常态,

SwooleDistributed 是swoole分布式系统的实现，他提供了一套基于swoole扩展的分布式通讯框架。 结构图： SwooleDistributed 不仅提供了分布式搭建的必要设施，还提供了4大组件帮助你提高编写代码的效率，你既可以部署成单机模式也可以搭配dispatch模块构建集群系统。 有别于传统的MVC架构，SwooleDistributed 主要应对的是rpc服务或者是通讯服务，也就是说MVC中的View模块是没有实际意义的，所以在SwooleDistributed 中仅存在Model和Controller，另外为了方便开发我们额外添加了2个组件分别是Task和Timer。 Task组件主要是处理异步任务，由于Task的设计结构简单只适合用于辅助swoole的worker进程，处理简单并不复杂的异步操作，如果你将他作为复杂耗时并且频繁调用的组件那是不可取的。 Timer是封装好的定时器，他和Task组件关系密切，你可以通过Timer进行定时任务。 目前提供便利的还有异步的Redis连接池，你可以方便简单的使用redis异步服务而不用担心连接池的问题，我们已经优雅的解决了。但值得注意的是所有的异步服务都只允许在worker进程中调用，task进程只能调用同步服务。 未来将要实现的： 1.异步的mysql服务，建立管理mysql连接池。 2.mysql语法构建器

作者 | 晓土 阿里巴巴高级工程师 姊妹篇阅读推荐 ： 《 云原生时代，分布式系统设计必备知识图谱（内含22个知识点） 》 导读： 本文力求从分布式基础理论、架构设计模式、工程应用、部署运维、业界方案这几大方面，介绍基于 MSA（微服务架构）的分布式知识体系大纲，从而对 SOA 到 MSA 进化有着立体的认识；从概念上和工具应用上更近一步了解微服务分布式的本质，身临其境的感受如何搭建全套微服务架构的过程。 关注“阿里巴巴云原生”公众号，回复“ 分布 ”，即可下载分布式系统及其知识体系清晰大图！ 随着移动互联网的发展和智能终端的普及，计算机系统早就从单机独立工作过渡到多机器协作，集群按照分布式理论构建出庞大复杂的应用服务，在分布式的基础上正进行一场云原生的技术革命，彻底打破传统的开发方式，解放了新一代的生产力。 分布式系统知识体系大图 关注“阿里巴巴云原生”公众号，回复“ 分布 ”，即可下载分布式系统及其知识体系清晰大图！ 基础理论 SOA 到 MSA 的进化 SOA 面向服务架构 由于业务发展到一定程度后，需要对服务进行解耦，进而把一个单一的大系统按逻辑拆分成不同的子系统，通过服务接口来通讯。面向服务的设计模式，最终需要总线集成服务，而且大部分时候还共享数据库，出现单点故障时会导致总线层面的故障，更进一步可能会把数据库拖垮，所以才有了更加独立的设计方案的出现。 MSA 微服务架构