并行处理

前言 架构师需要了解并发与并行的区别，为高并发的处理打下基础 一、并发 1.并发图例 上图中，每个黑体代表一个事件发生，各个事件之间的发生时间段互不相交！ 这是微观上来看不是同时发生的，也就是说同一时刻只能有一个事件发生。 但是一个事件用时特别短，比如0.0001秒，那么从宏观上来看，可以把这几个事件当成是同时发生的。 2.并发概念 指在同一时刻只能有一条指令执行，但多个线程被快速的轮换执行，使得在宏观上具有多个线程同时执行的效果，但在微观上并不是同时执行的，只是把时间分成若干段，使多个线程快速交替的执行。 二、并行 1.并行图例 上图中，每个黑体代表一个事件发生，各个事件之间的发生时间段可以相交！ 无论是微观还是宏观上来看都是同时发生的，也就是说同一时刻有多个事件发生。 2.并行概念 指在同一时刻，有多条指令在多个处理器上同时执行。所以无论从微观还是从宏观来看，二者都是一起执行的。 三、与CPU的联系 打开任务管理器中的性能： 从上图可以看到处理器的个数以及线程数。CPU就是中央处理器 下面画一个具有6个中央处理器的电脑： 处理器1运行多个线程，这是并发；6个处理器之间的线程的运行就是并行， 实际上一个处理器不会只处理一个线程！ 所以，可以总结如下： ▲单处理器只能发生并发，不会发生并行！ ▲多处理器必然发生并行，其中每个处理器发生并发！

5.7.2 支持单库增强型多线程slave(多个sql work线程)，mariadb 10.0.5支持 原理 slave利用事务组提交的特性( To provide parallel execution of transactions in the same schema, MariaDB 10.0 and MySQL 5.7 take advantage of the binary log group commit optimization )，在slave 多个sql worker线程进行并行回放 master依据group commit的并行性，在binary log进行标记，slave使用master提供的信息并行执行事务 注意事项 级联复制场景，其他slave将会出现并行性更小(并行度不一样)，使用binlog server做替代方案 配置 mysql 5.7 slave_parallel_type=logical_clock 默认为database，使用db并行方式，logical_clock使用逻辑时钟的并行模式 slave_parallel_workers=16 设置worker线程数 binlog_group_commit_sync_delay 和 binlog_group_commit_sync_no_delay_count 在master延时事务提交

故事背景: GCD的死锁问题,一直是在使用多线程的时候,一个比较绕也必须要注意的问题,今天在工作中我们几个同事又讨论到了这个话题,通过和大伙的交流,发现不少的同事还是有绕不明白的地方, 我就想到,要不我来写一个关于GCD死锁的专题好了,于是就有了这篇关于GCD死锁的专题: (下方的理解,仅限于我个人的理解,有不妥的地方,望大家斧正!) 如果您有任何意见或建议也可以通过 邮件 或 微博 联系我 环境信息: Mac OS X 10.11.3 Xcode 7.2 iOS 9.2 阐述: ####1. 什么是GCD ? GCD，全称 Grand Central Dispatch。可翻译为”牛逼的中枢调度器”。它是纯C语言的，提供了非常多强大的函数。 Grand是宏伟的、极重要的意思。 GCD是提供了功能强大的任务和队列控制功能，相比于NSOperation更加底层，虽然现象苹果极力的推荐使用NSOperation来解决多线程问题, 但是,就目前市场上大部分企业的iOS开发团队而言, GCD仍然还是大头, NSOperation也只会逐步的来替代GCD, 因此在开线程的时候,如果不注意也会导致一些问题, 比如死锁。 ####2.什么是GCD死锁 ? 所谓死锁，通常指有两个线程A和B都卡住了，A在等B ,B在等A,相互等待对方完成某些操作。A不能完成是因为它在等待B完成。但B也不能完成

1.1.1 常规性能调优一：最优资源配置 Spark性能调优的第一步，就是为任务分配更多的资源，在一定范围内，增加资源的分配与性能的提升是成正比的，实现了最优的资源配置后，在此基础上再考虑进行后面论述的性能调优策略。 资源的分配在使用脚本提交Spark任务时进行指定，标准的Spark任务提交脚本如代码清单2-1所示：、 /usr/opt/modules/spark/bin/spark-submit \ --class com.atguigu.spark.Analysis \ --num-executors 80 \ --driver-memory 6g \ --executor-memory 6g \ --executor-cores 3 \ /usr/opt/modules/spark/jar/spark.jar \ 可以进行分配的资源如表2-1所示： 表2-1 可分配资源表 名称 说明 --num-executors 配置Executor的数量 --driver-memory 配置Driver内存（影响不大） --executor-memory 配置每个Executor的内存大小 --executor-cores 配置每个Executor的CPU core数量 调节原则：尽量将任务分配的资源调节到可以使用的资源的最大限度。 对于具体资源的分配

原文 ： Performance With Java8 Streams 作者 ：Arun Pandey 翻译 ：雁惊寒 摘要：本文介绍了Java8中流的几个特性，以告诫开发者流并不是高性能的代名词，需谨慎使用流。以下是译文。 流（Stream）是Java8为了实现最佳性能而引入的一个全新的概念。在过去的几年中，随着硬件的持续发展，编程方式已经发生了巨大的改变，程序的性能也随着并行处理、实时、云和其他一些编程方法的出现而得到了不断提高。 Java8中，流性能的提升是通过 并行化（parallelism） 、 惰性（Laziness） 和 短路操作（short-circuit operations） 来实现的。但它也有一个缺点，在选择流的时候需要非常小心，因为这可能会降低应用程序的性能。 下面来看看这三项支撑起流强大性能的因素吧。 并行化 流的并行化充分利用了硬件的相关功能。由于现在计算机上通常都有多个CPU核心，所以在多核系统中如果只使用一个线程则会极大地浪费系统资源。设计和编写多线程应用非常具有挑战性，并且很容易出错，因此，流存在两种实现：顺序和并行。使用并行流非常简单，无需专业知识即可轻松处理多线程问题。 在Java的流中，并行化是通过 Fork-Join 原理来实现的。根据 Fork-Join 原理，系统会将较大的任务切分成较小的子任务（称之为 forking ）

翻译自 PGI Compiler User's Guide 1.6. 使用PGI编译器进行并行编程 PGI编译器支持多种样式的并行编程： 使用pgf77，pgf95，pgfortran，pgcc或pgc +++的-⁠Mconcur选项的 自动共享内存并行程序（Automatic shared-memory parallel programs ）的 编译。此类并行程序可以在共享内存并行（shared-memory parallel，SMP）系统上运行，例如双核或多处理器工作站。 使用pgf77，pgf95，pgfortran，pgcc或pgc +++的-⁠mp选项 的 OpenMP共享内存并行程序 的编译。这种并行程序可以在SMP系统上运行。使用OpenMP 指令编译的并行程序通常可以在双核工作站或SMP服务器系统上的大量处理器上实现显著的加速。 使用 OpenMP 一节包含用户控制的并行编程的完整说明。 使用基于分布式进程之间通信的MPI消息传递库进行分布式计算。 使用低级模型（例如CUDA Fortran）或高级模型（例如PGI加速器模型或OpenACC）来加速计算，以针对多核GPU或其他附加的加速器为目标。 前两种并行程序统称为SMP并行程序。 在单个硅芯片上，当今的CPU集成了两个或多个完整的处理器内核-功能单元，寄存器，一级缓存，二级缓存等。这些CPU被称为多核处理器

Spark中的数据倾斜问题主要指shuffle过程中出现的数据倾斜问题，是由于不同的key对应的数据量不同导致的不同task所处理的数据量不同的问题。 例如，reduce点一共要处理100万条数据，第一个和第二个task分别被分配到了1万条数据，计算5分钟内完成，第三个task分配到了98万数据，此时第三个task可能需要10个小时完成，这使得整个Spark作业需要10个小时才能运行完成，这就是数据倾斜所带来的后果。 注意，要区分开数据倾斜与数据量过量这两种情况，数据倾斜是指少数task被分配了绝大多数的数据，因此少数task运行缓慢；数据过量是指所有task被分配的数据量都很大，相差不多，所有task都运行缓慢。 数据倾斜的表现： 1. Spark作业的大部分task都执行迅速，只有有限的几个task执行的非常慢，此时可能出现了数据倾斜，作业可以运行，但是运行得非常慢； 2. Spark作业的大部分task都执行迅速，但是有的task在运行过程中会突然报出OOM，反复执行几次都在某一个task报出OOM错误，此时可能出现了数据倾斜，作业无法正常运行。 定位数据倾斜问题： 1. 查阅代码中的shuffle算子，例如reduceByKey、countByKey、groupByKey、join等算子，根据代码逻辑判断此处是否会出现数据倾斜； 2. 查看Spark作业的log文件

算子调优一：mapPartitions 普通的map算子对RDD中的每一个元素进行操作，而mapPartitions算子对RDD中每一个分区进行操作。如果是普通的map算子，假设一个partition有1万条数据，那么map算子中的function要执行1万次，也就是对每个元素进行操作。 如果是mapPartition算子，由于一个task处理一个RDD的partition，那么一个task只会执行一次function，function一次接收所有的partition数据，效率比较高。 比如，当要把RDD中的所有数据通过JDBC写入数据，如果使用map算子，那么需要对RDD中的每一个元素都创建一个数据库连接，这样对资源的消耗很大，如果使用mapPartitions算子，那么针对一个分区的数据，只需要建立一个数据库连接。 mapPartitions算子也存在一些缺点：对于普通的map操作，一次处理一条数据，如果在处理了2000条数据后内存不足，那么可以将已经处理完的2000条数据从内存中垃圾回收掉；但是如果使用mapPartitions算子，但数据量非常大时，function一次处理一个分区的数据，如果一旦内存不足，此时无法回收内存，就可能会OOM，即内存溢出。 因此，mapPartitions算子适用于数据量不是特别大的时候

1.1.1 常规性能调优一：最优资源配置 Spark性能调优的第一步，就是为任务分配更多的资源，在一定范围内，增加资源的分配与性能的提升是成正比的，实现了最优的资源配置后，在此基础上再考虑进行后面论述的性能调优策略。 资源的分配在使用脚本提交Spark任务时进行指定，标准的Spark任务提交脚本如代码清单2-1所示：、 /usr/opt/modules/spark/bin/spark-submit \ --class com.atguigu.spark.Analysis \ --num-executors 80 \ --driver-memory 6g \ --executor-memory 6g \ --executor-cores 3 \ /usr/opt/modules/spark/jar/spark.jar \ 可以进行分配的资源如表2-1所示： 表2-1 可分配资源表 名称 说明 --num-executors 配置Executor的数量 --driver-memory 配置Driver内存（影响不大） --executor-memory 配置每个Executor的内存大小 --executor-cores 配置每个Executor的CPU core数量 调节原则：尽量将任务分配的资源调节到可以使用的资源的最大限度。 对于具体资源的分配

转载于优秀博主: https://blog.csdn.net/weixin_30363263/article/details/80732156 你吃饭吃到一半，电话来了，你一直到吃完了以后才去接，这就说明你不支持并发也不支持并行。 你吃饭吃到一半，电话来了，你停了下来接了电话，接完后继续吃饭，这说明你支持并发。 （不一定是同时的） 你吃饭吃到一半，电话来了，你一边打电话一边吃饭，这说明你支持并行。 并发的关键是你有处理多个任务的能力，不一定要同时。 并行的关键是你有同时处理多个任务的能力。 所以我认为它们最关键的点就是：是否是『 同时 』。 并发是轮流处理多个任务，并行是同时处理多个任务 . 来源： https://www.cnblogs.com/PinkPink/p/11950245.html