分布式开发

1、搭建mogilefs MogileFS是一个开源的分布式文件存储系统，由LiveJournal旗下的Danga Interactive公司开发。Danga团队开发了包括 Memcached、MogileFS、Perlbal 等多个知名的开源项目。目前使用MogileFS 的公司非常多，如日本排名先前的几个互联公司及国内的yupoo(又拍)、digg、豆瓣、1号店、大众点评、搜狗和安居客等，分别为所在的组织或公司管理着海量的图片。 MogileFS由3个部分组成： (1) server：主要包括mogilefsd和mogstored两个应用程序。mogilefsd实现的是tracker，它通过数据库来保存元数据信息，包括站点domain、class、host等；mogstored是存储节点(store node)，它其实是个WebDAV服务，默认监听在7500端口，接受客户端的文件存储请求。在MogileFS安装完后，要运行mogadm工具将所有的store node注册到mogilefsd的数据库里，mogilefsd会对这些节点进行管理和监控。 (2) utils（工具集）：主要是MogileFS的一些管理工具，例如mogadm等。 (3) 客户端API：MogileFS的客户端API很多，例如Perl、PHP、Java、Python等，用这个模块可以编写客户端程序

锁在我们的日常开发可谓用得比较多。通常用来解决资源并发的问题。特别是多机集群情况下，资源争抢的问题。但是，很多新手在锁的处理上常常会犯一些问题。今天我们来深入理解锁。 一、Redis 锁错误使用之一 我曾经见过有的项目把查询结果存储到 Redis 当中时的伪代码如下： $redis = new \Redis('127.0.0.1', 6379); $cacheKey = 'query_cache'; $result = $redis->get($cacheKey); if ($result) { // 缓存有效则直接返回。 return $result; } else { // 缓存失效则重新获取并存储到 Redis。 $mysqlResult = []; $redis->set($cacheKey, json_encode($mysqlResult), 3600); return $mysqlResult; } 初看代码并不会发现问题所在。通常情况下，当服务器资源压力非常小的时候，这段代码不会有任何问题。并且，真的可以提升服务器吞吐性能。 假如，这个位置的代码出现了单点压力呢？比如，这个功能是统计结果，查询数据库需要花 5s。而且，由于该功能比较常用，单位时间内达到了 1000 次/秒。 这时就会出现并发穿透问题。 1000 个请求同时到达这个程序位置，都去读取缓存是否存在

Spark 简介 Spark 是整个 BDAS 的核心组件，是一个大数据分布式编程框架，不仅实现了MapReduce的算子map 函数和reduce函数及计算模型，还提供更为丰富的算子，如filter、join、groupByKey等。是一个用来实现快速而同用的集群计算的平台。 Spark将分布式数据抽象为弹性分布式数据集（RDD），实现了应用任务调度、RPC、序列化和压缩，并为运行在其上的上层组件提供API。其底层采用Scala这种函数式语言书写而成，并且所提供的API深度借鉴Scala函数式的编程思想，提供与Scala类似的编程接口。 Sparkon Yarn 从用户提交作业到作业运行结束整个运行期间的过程分析。 在这里还是要推荐下我自己建的大数据学习交流群:943791324，群里都是学大数据开发的，如果你正在学习大数据 ，小编欢迎你加入,大家都是软件开发党，不定期分享干货（只有大数据软件开发相关的），包括我自己整理的一份最新的大数据进阶资料和高级开发教程，欢迎进阶中和进想深入大数据的小伙伴加入。 一、客户端进行操作 1.根据yarnConf来初始化yarnClient，并启动yarnClient 2.创建客户端Application，并获取Application的ID，进一步判断集群中的资源是否满足executor和ApplicationMaster申请的资源

SequoiaDB 巨杉数据库 3.0 ，在产品GA发布后，经过近半年在金融级场景的测试、上线和稳定运行之后，于近期正式发布。 1. SequoiaDB 3.0 产品定位 SequoiaDB巨杉数据库是一款金融级分布式数据库，包括了分布式NewSQL、分布式文件系统与对象存储、与高性能NoSQL三种存储模式，分别对应分布式在线交易、非结构化数据和内容管理、以及海量数据管理和高性能访问场景。 根据Gartner的数据库报告，Multi-model多模是未来10年，下一代分布式数据库发展的最主要方向。从1.0的高性能分布式 NoSQL数据库，到2.0加入的分布式对象存储，再到3.0完整协议级兼容MySQL，SequoiaDB经过6年的不断迭代创新，全面支持企业级结构化、半结构化以及非结构化数据存储。 SequoiaDB 3.0 产品维度 2. MySQL 完整协议级兼容 SequoiaDB 3.0实现了100%的MySQL协议级兼容： · 全面兼容：全面支持MySQL协议与语法，用户可以直接使用MySQL客户端或任何管理、开发与监控工具对数据库进行操作； · MySQL语法：由于使用了MySQL原生的解析器，SequoiaDB 3.0 能够实现100%的MySQL语法兼容，支持语法包括基础CRUD操作，多表关联，跨节点事务操作，创建视图，存储过程，索引和访问计划等。 · 无缝切换：

摘自： https://www.cnblogs.com/xiaoXuZhi/p/xyh_trans_distributed.html 关于分布式事务的实现梳理 关于分布式事务的实现梳理 场景描述 　　在实际开发过程中，往往会遇到微服务架构中（数据分区存储），用户的一个操作，会设计到多个模块的数据落地或者更新查找，并且每个模块数据都是存储在不同的数据库，并且业务要求还需要确保操作结果的一致性。比如，用户在下单时：首选需要落地订单数据，其次，需要落地：账单数据、日志数据、或者库存更新等等操作。首先我们想到的解决方式就是事务来实现，由于在不同库，所以需要涉及到分布式事务。 解决方案 　　为了达到上述要求，在实现上根据我的经验大概有如下3种实现方式： 　　其一、分布式事务 　　　　分布式事务就是采用微软提高的分布式事务机制实现，在实现效率上不是很理想，并且也不是符合微服务设计的单一功能原则，所以不是很建议使用。 　　其二、消息队列 　　　　消息队列是现在使用的比较多的解决方案，通过一些消息队列中间件， 实现逻辑解耦，异步实现，响应效率也大大提升。 　　其三、异步作业 　　　　异步作业的实现思路和消息队列类似，都是对操作的步骤的解耦，异步实现，但是在处理上有一定的延迟性，因为异步作业是周期性的执行，但是异步作业也是对消息队里的一个保障和补充。 　　　　在实际使用过程中

ElasticSearch概述 1.介绍 **lucene问题：** 1.lucene是java开发的，对于不会java的人使用比较困难 2.lucene代码简化问题 3.分布式与高可用问题 **ElasticSearch：** 1.基于lucene的搜索服务器 2.提供一个分布式高可用多用户能力的全文检索引擎 3.基于RESTful web接口 4.java开发，但是以接口形式对外暴露 2.ElasticSearch结构 **包括三大部分：** 底层数据存储：维护索引文件，利用分布式数据切分存储，可以存在本地，也可以存在hdfs 封装lucene扩展功能：发现集群节点功能，支持各种对资源的管理 接口层：给用户提供访问接口（http协议，REST风格），用户可以通过url访问地址，通过请求方式， 对索引进行CRUD操作 来源： https://blog.csdn.net/weixin_43356218/article/details/102729285

关于分布式事务的实现梳理 场景描述 　　在实际开发过程中，往往会遇到微服务架构中（数据分区存储），用户的一个操作，会设计到多个模块的数据落地或者更新查找，并且每个模块数据都是存储在不同的 数据库 ，并且业务要求还需要确保操作结果的一致性。比如，用户在下单时：首选需要落地订单数据，其次，需要落地：账单数据、日志数据、或者库存更新等等操作。首先我们想到的解决方式就是事务来实现，由于在不同库，所以需要涉及到分布式事务。 解决方案 　　为了达到上述要求，在实现上根据我的经验大概有如下3种实现方式： 　　其一、分布式事务 　　　　分布式事务就是采用微软提高的分布式事务机制实现，在实现效率上不是很理想，并且也不是符合微服务设计的单一功能原则，所以不是很建议使用。 　　其二、消息队列 　　　　消息队列是现在使用的比较多的解决方案，通过一些消息队列中间件， 实现逻辑解耦，异步实现，响应效率也大大提升。 　　其三、异步作业 　　　　异步作业的实现思路和消息队列类似，都是对操作的步骤的解耦，异步实现，但是在处理上有一定的延迟性，因为异步作业是周期性的执行，但是异步作业也是对消息队里的一个保障和补充。 　　　　在实际使用过程中，一般都是消息队列和异步作业配套实现，当消息队列出现问题，异步作业能正常的把流程走完。 　　分布式事务 　　在介绍分布式事务时，分两部分来介绍：sql分布式事务、ADO

1、大数据流程图 2、大数据各个环节主要技术 在这里还是要推荐下我自己建的 大数据学习交流群:9437**91324 ，群里都是学大数据开发的，如果你正在学习大数据 ，小编欢迎你加入,大家都是软件开发党，不定期分享干货（只有大数据软件开发相关的），包括我自己整理的一份最新的大数据进阶资料和高级开发教程，欢迎进阶中和进想深入大数据的小伙伴加入。 2.1、数据处理主要技术 Sqoop ：（发音：skup）作为一款开源的离线数据传输工具，主要用于Hadoop(Hive) 与传统数据库（MySql,PostgreSQL）间的数据传递。它可以将一个关系数据库中数据导入Hadoop的HDFS中， 也可以将HDFS中的数据导入关系型数据库中。 Flume： 实时数据采集的一个开源框架，它是Cloudera提供的一个高可用用的、高可靠、分布式的海量日志采集、聚合和传输的系统。目前已经是Apache的顶级子项目。使用Flume可以收集诸如日志、时间等数据 并将这些数据集中存储起来供下游使用（尤其是数据流框架，例如Storm）。和Flume类似的另一个框架是Scribe（FaceBook开源的日志收集系统，它为日志的分布式收集、统一处理提供一个可扩展的、高容错的简单方案） 　Kafka： 通常来说Flume采集数据的速度和下游处理的速度通常不同步，因此实时平台架构都会用一个消息中间件来缓冲

阅读目录 　　 什么事分布式锁 　　基于redis实现分布式锁 　 一、什么是分布式锁 我们在开发应用的时候，如果需要对某一个共享变量进行多线程同步访问的时候，可以使用我们学到的锁进行处理，并且可以完美的运行，毫无Bug！ 注意这是单机应用，后来业务发展，需要做集群，一个应用需要部署到几台机器上然后做负载均衡，大致如下图： 上图可以看到，变量A存在三个服务器内存中（这个变量A主要体现是在一个类中的一个成员变量，是一个有状态的对象），如果不加任何控制的话，变量A同时都会在分配一块内存，三个请求发过来同时对这个变量操作，显然结果是不对的！即使不是同时发过来，三个请求分别操作三个不同内存区域的数据，变量A之间不存在共享，也不具有可见性，处理的结果也是不对的！ 如果我们业务中确实存在这个场景的话，我们就需要一种方法解决这个问题！ 为了保证一个方法或属性在高并发情况下的同一时间只能被同一个线程执行，在传统单体应用单机部署的情况下，可以使用并发处理相关的功能进行互斥控制。但是，随着业务发展的需要，原单体单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，单纯的应用并不能提供分布式锁的能力。为了解决这个问题就需要一种跨机器的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题！ 分布式锁应该具备哪些条件： 　

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