分布式开发

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

　　emm~ 写这篇博客只是手痒，因为开发环境用单节点就够了，生产环境肯定是真实集群，所以这个伪分布式纯属娱乐而已。 配置HDFS 1. 安装好一台hadoop,可以参考这篇博客。 2. 在hadoop目录下编辑文件指定java环境变量 vim ./etc/hadoop/hadoop-env.sh 　　 3.指定hdfs存储位置和地址 vim etc/hadoop/core-site.xml <configuration> <!-- 指定HDFS中NameNode的地址 --> <property> <name>fs.defaultFS</name> <value>hdfs://127.0.0.1:9000</value> </property> <!-- 指定Hadoop运行时产生文件的存储目录 --> <property> <name>hadoop.tmp.dir</name> <value>/usr/local/wulei/hadoop-2.7.2/data/tmp</value> </property> </configuration> core-site.xml 　　 4. 指定hdsf副本数量 vim etc/hadoop/hdfs-site.xml <configuration> 　　　　<!-- 指定HDFS副本的数量 --> 　　　　<property> 　　　　

转载自 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

#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和文件等等，并且当分布式节点之间有关联时，还得考虑之间的通讯，另外，节点非常多的时候，得有监控和管理来支撑。这样看起来， 分布式是一个非常庞大的体系 ，只不过你 可以根据具体需求进行适当地裁剪

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并没有将该系统的软件部分作为开源软件发布。 下面分布式文件系统都是类

常见的 分布式文件系统 有， 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） ----------------

一、什么是 session 共享 ？ 如上图，是一个简单的分布式环境，以登录来说，当用户发出请求，通过负载均衡，可能会走tomcat1服务器，也可能会走tomcat2服务器，此时就有可能，我们在tomcat1上实现了登录，保存了session，但是tomcat2并没有保存，当有请求到tomcat2时，我们就需要重新登录，这就是session没有共享的实例。保持tomcat1和tomcat2的session数据同步，就是session共享。 二、session 共享的实现 服务端实现session的复制或共享 在实际开发中，可能不只有tomcat1和tomcat2两台服务器，当服务器数量很多的时候，该方法会造成资源浪费。 使用第三方数据库（如：redis） 在客户端维护 session 登录成功后，写入一个cookie，根据cookie判断用户状态 来源： CSDN 作者： eaphy 链接： https://blog.csdn.net/eaphyy/article/details/81177442

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

一、什么是session session在计算机中，尤其是在网络应用中，称为”会话控制“。Session对象存储特定用户会话所需的属性及配置信息。这样，当用户在应用程序的web页面之间跳转时，存储在session对象中的变量将不会丢失，而在整个用户会话中一直存在下去。 二、产生session不一致原因 单台tomcat没有任何问题，但现在是集群的tomcat因此就存在session不一致问题。如图 三、解决方案 （1）session复制 tomcat的session复制，可以实现session共享 优点：不需要额外开发，只需搭建tomcat集群即可 缺点：tomcat 是全局session复制，集群内每个tomcat的session完全同步（也就是任何时候都完全一样的) 在大规模应用的时候，用户过多，集群内tomcat数量过多，session的全局复制会导致集群性能下降， 因此，tomcat的数量不能太多，5个以下为好。 （2）session绑定 当用户A第一次访问系统时，tomcat1对其进行服务，那么，下次访问时仍然让tomcat1对其进行服务 （3）使用redis集中管理session 可以将用户的会话保存在redis中，每次从redis中查询用户信息，就可以很好的解决会话共享问题。如图： 四、实际应用 （1）用户登录问题 对于大型分布式系统，可以使用单点登录系统进行登录

最近，在工作中遇到一个问题，问题描述：一个用户在登录成功以后会把用户信息存储在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中的信息加密。