分布式开发

场景： 进入搜狗，输入搜索关键字进行搜索 利用多进程分布式实现 from multiprocessing import Pool import os, time from selenium import webdriver from selenium.webdriver.common.keys import Keys from multiprocessing import Manager, current_process import traceback #定义测试行为函数：此处为打开搜狗搜索内容 def node_task(name, lock, arg, successTestCases, failTestCases): """ :param name: 执行进程名 :param lock:进程间的共享资源锁 :param arg:node节点计算机、浏览器字典 ，如：{"node": "http://127.0.0.1:6666/wd/hub", "browserName": "chrome"} :param successTestCases:成功执行用例列表 :param failTestCases:失败用例列表 :return:返回成功执行、失败执行的用例列表 """ procName = current_process().name print("当前进程名:"

群里经常卧虎藏龙，转载一篇百度大牛，投稿原创文章，大家交流学习 ，欢迎更多朋友投稿，发布原创文章和干货和大家分享交流。 引言 在互联网系统中，理想的情况下，肯定是希望系统能够同时满足“一致性”、“可用性”和“分区容忍性”。 但是基于熟悉的CAP定律也好，还是BASE理论， 我们知道，在实际情况中是不可能实现的。而在金融领域，一致性是最为关注的特性，任何情况下都必须满足一致性。关于CAP定律和BASE理论，本文不再介绍，有兴趣的同学可以自行百度一下。本文重点来阐述下关于一致性的方案，包括强一致性和最终一致性。 而在互联网领域， 很多情况下都是牺牲强一致性，来达到高可用性， ϵ 统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。 数据库本地事务 数据库事务肯定是强一致性的方案，而且是一致性最简单的方案，因为一致性是数据库的事务来保证的，业务层不需要关心细节。比较典型的应用是在返现场景下，针对带有返现的交易的退款，需要一次性退两笔交易单，采用的就是通过数据库本地事务来完成的。具体如下： 用户A花了100元购买商户B的商品，购买结束后返现给用户A 2元。 这是两笔交易，原始交易是100元，返现交易是2元。 那么发生退款时，需要保证两笔交易同时都退款。这个就是直接采用数据库本地事务实现的，即一次退款请求，两笔交易同时退款。 总结： 数据库事务的优点是简单

分布式、微服务、云架构 JAVA语言开发、跨平台、高性能、高可用、安全、服务化、模块化、组件化、驱动式开发模式 从现在开始，我这边会将近期研发的springcloud微服务云架构的搭建过程和精髓记录下来，帮助更多有兴趣研发spring cloud框架的朋友，希望可以帮助更多的好学者。大家来一起探讨spring cloud架构的搭建过程及如何运用于业项目。 原文：http://blog.51cto.com/13545858/2150622

HangFire的拓展和使用 看了很多博客，小白第一次写博客。 最近由于之前的任务调度框架总出现问题，因此想寻找一个替代品，之前使用的是Quartz.Net，这个框架方便之处就是支持cron表达式适合复杂日期场景使用，以及秒级任务。但是配置比较复杂，而且管理不方便，自己开发了个web管理页面，不过这个需要额外的单独线程去统一管理工作状态，很容易出现问题。 有考虑过 “FluentScheduler” ，使用简单，但是管理配置也很麻烦，我希望能做到配置简单，管理方便，高性能。最后想到了以前听过的hangfire，它的好处就是自带控制面板，在园子里看了很多相关资料，偶然发现了有人拓展过 hangfire 通过调用api接口来执行任务，这种方式可以避免依赖本地代码，方便部署，在此基础上，我用空闲时间拓展了一下现在已经基本可以满足需求。 所拓展的功能全部属于外部拓展,因此hangfire版本可以一直更新，现在已经更新最新版，支持秒级任务 gitHub地址 由于更新到最新版hangfire 1.7支持秒级任务，使用的在线表达式生成部分表达式有问题,注掉了秒级任务表达式生成，有时间需要详细测试更改,可以参考( hangfire官方提供的表达式 ) 现在已经实现的功能有： 1， 部署及调试 ：只需要配置数据库连接，然后编译即可运行，无需建表，支持（redis，mysql, sqlserver

本文根据黄炎在2018年7月7日【MySQL技术沙龙 ・ 成都站】现场演讲内容整理而成。 黄炎 爱可生研发总监，深入钻研分布式数据库相关技术，擅长业界相关MySQL中间件产品和开发，以及分布式中间件在企业内部的应用实践。 MySQL中间件性能测试 I 摘要： 我今天代表我的团队向大家来介绍一下MySQL中间件性能的测试，为大家带来一些不太一样的故事，包括我们在做性能测试的时候一些不太一样的视角。 分享大纲： 1.性能测试的常见的(错误)方法 * 3 2.性能测试的一些(我们用的)方法 * 2 3.分布式事务相关 * 1 我今天代表我的团队向大家来介绍一下MySQL中间件性能的测试，之所以讲选这个主题是因为我注意到大家都是高级的DBA，我们也有很多的高级的DBA，跟大家聊天的时候都会注意到，大家对于性能测试的第一印象： 性能 = sysbench 测试 = run 结果 = tps 数值要高大上 性能就是sysbench，然后测试就是跑一下，这就叫性能测试了，结果就是要TPS或者QPS，数值一定要高大上，这是大家对性能测试测试的第一印象也可能是唯一的印象。我们公司是属于乙方的技术服务提供商，我们对业界的很多产品进行过性能测试，所以今天想为大家带来一些不太一样的故事，以及我们在做性能测试的时候一些视角。 我今天大概会向大家介绍三件事情： 第一件事情 是我们观察到，大家在做性能测试的时候

Linux介绍 1 介绍 Linux操作系统是基于UNIX操作系统发展而来的一种克隆系统，它诞生于1991 年的 10 月5 日（这是第一次正式向外公布的时间）。 以后借助于Internet网络，并通过全世界各地计算机爱好者的共同努力，已成为今天世界上使用最多的一种UNIX 类操作系统，并且使用人数还在迅猛增长。 2 诞生 1991 年初，林纳斯・托瓦兹开始在一台386sx 兼容微机上学习minix 操作系统。通过学习，他逐渐不能满足于minix 系统的现有性能，并开始酝酿开发一个新的免费操作系统。 1991 年的10 月5 日，林纳斯・托瓦兹在comp.os.minix 新闻组上发布消息，正式向外宣布Linux 内核系统的诞生（Free minix-like kernel sources for 386-AT）。这段消息可以称为Linux 的诞生宣言，并且一直广为流传。 3 版本 主流的Linux发行版：Ubuntu， CentOS, Red Hat， DebianGNU/Linux ，Fedora，Gentoo，MandrivaLinux ，PCLinuxOS，SlackwareLinux ，openSUSE，ArchLinux，Puppylinux，Mint, 等。 大陆发行版：中标麒麟Linux(原中标普华Linux)， 红旗Linux(Red-flag Linux)

器，智能路由，微代理，控制总线）。 分布式系统的协调导致了样板模式, 使用Spring Cloud开发人员可以快速地支持实现这些模式的服务和应用程序。 他们将在任何分布式环境中运行良好，包括开发人员自己的笔记本电脑，裸机数据中心，以及Cloud Foundry等托管平台。 版本：Dalston.RELEASE 特性 Spring Cloud专注于提供良好的开箱即用经验的典型用例和可扩展性机制覆盖。 分布式/版本化配置 服务注册和发现 路由 service - to - service调用 负载均衡 断路器 分布式消息传递 来源： https://www.cnblogs.com/borter/p/11762828.html

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

事务就是一个会话过程中，对上下文的影响是一致的，要么所有的更改都做了，要么所有的更变都撤销掉。就要么生，要么死。没有半死不死的中间不可预期状态。 参考下薛定谔的猫。 事务是为了保障业务数据的完整性和准确性的。 分布式事务，常见的两个处理办法就是两段式提交和补偿。 两段式提交典型的就是XA，有个事务协调器，告诉大家，来都准备好提交，大家回复，都准备好了，然后协调器告诉大家，一起提交，大家都提交了。 补偿比较好理解，先处理业务，然后定时或者回调里，检查状态是不是一致的，如果不一致采用某个策略，强制状态到某个结束状态（一般是失败状态），然后就世界太平了。典型的就是冲正操作。 准备好了以后，如果没有问题，收到提交，所有人都开始提交。 这个时候，比如对数据库来说，有redo日志的。 如果某个数据库这时候宕机了，那么它重启的时候，先执行检查，也会把上一次的这些操作都提交掉的。所以各个点的数据都是一致的。 问题 1：比如 一个业务要调用很多的服务都是写操作，如果有其中一个写的服务失败了，怎么办 ？假设 4个写的吧，有2个写失败了 。 kimmking：淘宝之类的网站一般的做法是，如果4个都成功才算成功，那么这次提交时4个写都设置成一个中间状态，先容许不一致。然后4个执行完成了以后，回调或是定时任务里检查这4个数据是不是一致的，如果一致就全部置为成功状态，如果不一致就全部置为失败。

Elasticsearch简介 * Elasticsearch是一个 实时的 分布式搜索和分析引擎。它可以帮助你用前所未有的速度去处理大规模数据。 它可以用于 全文搜索， 结构化搜索以及 分析，当然你也可以将这三者进行组合。 Elasticsearch是一个 建立在全文搜索引擎 Apache Lucene™ 基础上的搜索引擎，可以说Lucene是当今最先进，最高效的全功能开源搜索引擎框架。 但是Lucene只是一个框架，要充分利用它的功能，需要使用JAVA，并且在程序中集成Lucene。需要很多的学习了解，才能明白它是如何运行的，Lucene确实非常复杂。 Elasticsearch使用Lucene作为内部引擎，但是在使用它做全文搜索时，只需要使用统一开发好的API即可，而不需要了解其背后复杂的Lucene的运行原理。 当然Elasticsearch并不仅仅是Lucene这么简单，它不但包括了全文搜索功能，还可以进行以下工作: 分布式实时文件存储，并将每一个字段都编入索引，使其可以被搜索。 实时分析的分布式搜索引擎。 可以扩展到上百台服务器，处理PB级别的结构化或非结构化数据。 这么多的功能被集成到一台服务器上，你可以轻松地通过客户端或者任何你喜欢的程序语言与ES的RESTful API进行交流。 Elasticsearch的 上手是非常简单的。它附带了很多 非常合理的默认值