粒度

▶ 总体印象：适合 OpenCL 入门的书，有丰富的代码和说明，例子较为简单。先把 OpenCL 代码的基本结构（平台 → 设备 → 上下文 → 命令队列 → 创建缓冲区 → 读写缓冲区 → 编译代码 → 创建程序 → 创建内核 → 设定内核参数 → 执行内核 → 缓冲区读写 → 回收检查结果）定死了，在围绕这个结构展开算法和应用。 ▶ 第一章，并行编程入门 ● 开放计算语言（Open Computuing Language，OpenCL） ● 设备语言可以高效映射到众多的内存系统构架上；主机端语言的目标是以较低的开销来高效管理复杂点的并行程序。两者共同为开发人员提供了一种从算法设计高效过渡到实现的途径。 ● 并发性（Concurrency）考虑的是同时发生两个或两个以上的活动。并行性（Parallelism）指的是以提高总体性能为明确目标，并行进行两个或两个以上任务。并行程序必须有并发性，但是并发程序不一定要保证并行性。 ●支持完全一致的共享内存模型，会在硬件上有较大开销，因为共享总线式设计瓶颈。 ● 粒度，定义为计算与通信之比。并行粒度首先与应用程序算法的内在特性。 　　■ 细粒度的并行，计算强度低；没有租后的任务来隐藏长时间的异步通信耗时；容易通过提供大量可管理的工作单元来实现负载均衡；如果粒度过细，则可能人物之间的通信和同步开开销过大 　　■ 粗粒度的并行，计算强度高

1、封锁粒度是什么？ 封锁对象的大小称为封锁的粒度 封锁对象：逻辑单元、物理单元 2、选择封锁粒度的原则？ 封锁粒度 和 系统的并发度 、 系统的开销 密切相关 封锁的粒度越大 数据库能够封锁的数据单元就越少，并发度就越小，系统开销也就越小 封锁的粒度越小 数据库能够封锁的数据单元就越多，并发度就越高，系统开销也就越大 因此封锁粒度是一把双刃剑，所以在一个系统当中如果能够提供多种封锁粒度以便不同的事务按照自己的需求选择就比较完美了 这就是所谓的：多粒度封锁 3、具体如何选择封锁粒度呢？ 需要处理大量元组的用户事务，以关系为封锁单元 需要处理多个关系的大量元组的用户事务，以数据库为封锁单元 只是处理少量元组的用户事务，以元组为封锁单元 4、多粒度封锁 以树形结构来表示多级封锁粒度 根节点是整个数据库，表示最大的数据粒度 叶节点是最小的数据粒度 三级粒度树 四级粒度树 5、多粒度封锁协议 允许粒度树中的每一个节点独立的被加锁 对一个节点加锁，意味着这个节点的所有后裔节点也同样被加上相同类型的锁 因此多粒度封锁中一个数据对象可能以两种方式封锁： 显式封锁、隐式封锁 6、显式封锁和隐式封锁 显式封锁: 直接加到数据对象上的封锁 隐式封锁:是该数据对象没有独立加锁，是由于其 上级结点加锁而使该数据对象加上了锁 显式封锁和隐式封锁的效果是一样的 显然这种封锁的效率很低，因此引入了一种新型封锁

目录 什么是协程 多线程 协程 协程的使用场景 协程使用示例 Invoke的缺陷 协程语法 开启协程 终止协程 挂起 协程的执行原理 什么是协程 在Unity中，协程（Coroutines）的形式是我最喜欢的功能之一，我都会使用它来控制需要定时的。 协同程序，在主程序运行的同时，开启另外一段逻辑处理，来协同当前程序的执行。 可能看了这段文字介绍还是有点模糊，其实可以用多线程来比较。 多线程 多线程，顾名思义，多条同时执行的线程。 最初，多线程的诞生是为了解决IO阻塞问题，如今多线程可以解决许多同样需要异步方法的问题（例如网络等）。 所谓异步，通俗点讲，就是我走我的线程，你走你的线程。当某个线程阻塞时，另一个线程不会受影响继续执行。 需要认识到的是，多线程并不是真正意义上的多条线程同时执行。 它的实际是将一个时间段分成若干个时间片，每个线程轮流运行一个时间片。 （如图，将执行步骤切分成极小的粒度，然后依次运行） 但是由于时间片粒度非常非常小，几乎看不出区别，所以程序执行效果跟真正意义上的并行执行效果基本一致。 多线程的缺陷 然而多线程有一个坏处，就是可能造成共享数据的冲突。 假如有一个变量i = 0, Step1_1的操作是进行++i操作，Step2_1的操作是进行--i操作。 我们预期最终结果i为0。 但由于操作切分得过小，可能会发生这样顺序的事： 线程1：访问i, 将0存到寄存器

一、背景 大家应该在从事软件开发领域工作时间有一段时间之后，就开始有画图的意识，不管是懵懂的学别人还是想更好的让其他人理解自己的一个观点。所谓“一图胜千言”，我们身处于软件开发这个水很深且要求精确的复杂领域里，要想把事情做好，最基本的是要把事情想明白，其次还要让相关的人能够明白你要说的东西，进行协作。 特别对于一位架构师来说，能否画得一手好图尤其重要，因为相关的干系人数较多，要让不同领域的人能够达成一个统一的认识，是一件不太容易但也是必须要做好的事情。 二、图为了解决什么问题 软件开发涉及的流程是：需求 --> 开发 --> 测试 --> 发布上线。 作图本身是个设计的工作，是个前期工作。那么从软件开发的整个生命周期来说，用到的图的地方是在前期的需求、开发阶段较多。在软件开发这个非常抽象的领域，只要涉及到多人协作，那么通过文字来进行交流叙述是非常晦涩难懂的，需要沟通好几遍才能理解达成一致也是比较常见的情况。那么我们画图，就是为了把不适合用言语表述的内容通过作图的方式呈现出来，让相关协作者有一个共同的具象的参照物。这个参照物可以有它的额外价值，是对软件长期价值的延伸，一份一致、清晰的设计图，可以给后续的软件迭代提供非常有帮助的决策依据。当然保证设计图与系统的一致本身也是件费精力的事情。 三、不同流程中适合运用的图 用例图 用例图是UML交互图中的一种，是指由参与者（Actor）、用例

本章介绍UML建模元素 1： Stereotype-也被称为类型、构造型 UML里的元素扩展，简单来说其功能就是在已有的类型上添加一些标记，类似于打个戳，从而生成新的东西。 简单的说加一句话来更加清楚准确描述这个类。 2： Actor（主角、参与者）-是在系统之外与系统交互的某人或某事物，在建模过程中处于核心地位。 参与者和系统之间有一个明确的边界，参与者只能存在于边界之外，边界之内的所有人和事物都不是参与者。 人或物都可以时参与者； 3：如何确定参与者-一定是启动业务的主角 4：业务主角和业务工人 业务主角（business actor）是参与者的一个版型，用于定义业务的主角，不依赖计算机系统。业务主角是与业务系统有着交互的人和事物，用来确定业务范围。 业务范围：项目所涉及的所有客户业务的客观存在；系统范围：软件将要实现对应业务的系统功能。 业务工人被动参与业务 5：参与者和干系人 干系人-是与要建设的这个系统有利益相关的一切人和事 参与者就是干系人代表，对系统提出要求来获得他所代表的涉众的利益。 用户（user），指的是系统的使用者，是参与者的代表，一个用户可以代理多个参与者。 角色（role），指的是参与者的职责，一个角色代表了系统中的一类职责。 6:用例：一种把现实世界的需求捕获下来的方法。用例定义了一组用例实例，其中每个实例都是系统所执行的一系列操作

转载自 Mongodb常见问题 一.数据库级锁 MongoDB的锁机制和一般关系数据库如 MySQL（InnoDB）, Oracle 有很大的差异，InnoDB 和 Oracle 能提供行级粒度锁，而 MongoDB 2.x 只能提供 库级粒度锁 ，这意味着当 MongoDB 一个写锁处于占用状态时，其它的读写操作都得干等。 MongoDB 使用的是“readers-writer”锁， 可以支持并发但有很大的局限性，当一个读锁存在,许多读操作可以使用这把锁，然而, 当一个写锁的存在，一个单一的写操作会 exclusively 持有该锁，同时其它读，写操作不能使用共享这个锁；举个例子，假设一个集合里有 10 个文档，多个 update 操作不能并发在这个集合上，即使是更新不同的文档。 初看起来库级锁在大并发环境下有严重的问题，但是 MongoDB 依然能够保持大并发量和高性能，这是因为 MongoDB 的锁粒度虽然很粗放，但是在锁处理机制和关系数据库锁有很大差异，主要表现在： MongoDB 没有完整事务支持，操作原子性只到单个 document 级别，所以通常操作粒度比较小； MongoDB 锁实际占用时间是内存数据计算和变更时间，通常很快； MongoDB 锁有一种临时放弃机制，当出现需要等待慢速 IO 读写数据时，可以先临时放弃，等 IO 完成之后再重新获取锁 在MongoDB

1.前言&基本介绍 　　 　　在原始的系统架构中，我们都由程序直接连接DB，随着业务的进一步开展，DB的压力越来越大，为了缓解DB的这一压力，我们引入了缓存，在程序连接DB中加入缓存层， 从而减轻数据库压力，而且缓存一般存在于内存中，相比于存在硬盘中的DB在读取速度上绝对是比DB高几个等级。下面我们来简单聊聊关于缓存几个东西 2.缓存的优缺点 　　　　缓存的优点就是“快”，一个快字基本能概括了。如上文说的加速读写，分流对数据库的压力，归根结底就是对快字的应用及其本身，缺点主要是如下三点： 　　　　　　1.数据不一致性：DB的数据与缓存中的数据不一致 　　　　　　2.开发成本：需要同时处理缓存层跟DB层的逻辑，增加了开发成本 　　　　　　3.维护成本：例如需要对缓存层进行一个监控，增加了运维的成本 3.缓存更新策略 　　　　在上面中我们说到数据不一致性，一般来说缓存也是需要有生命周期的，需要被更新或者删除，这样才能保持缓存的可控性，在缓存更新中有如下三点： 　　　　　　1.LR(F)U/FIFO算法删除：简单来说就是按照队列的形式对不常用的缓存进行删除，链表的形式来实现，具体可点这里 http://blog.csdn.net/maddemon/article/details/6650703 　　　　　　2.超时删除：在设置缓存的时候可以设置过期时间，在时间到期之后自动删除

《敏捷软件开发》读书笔记（2） 包的划分原则和度量方法 以下原则中，前三个有关粒度，关注于如何把类划分在包里，是自底向上的设计，是关于包的内聚性设计，但是要考虑可开发性和可重用性两者的平衡；而后三个有关耦合，关注包之间的关系，关于包的稳定性设计，是自顶向下的设计思考。 重用发布等价原则REP 重用的粒度=发布的粒度，重用的粒度就是发布的粒度，为重用而发布的包中，不应该包含任何不是为重用而设计的类，也就是不应该包含任何业务定制、环境定制多代码。另外，也要考虑划分，不能强迫使用者引入他们不需要的类。 共同重用原则CRP 一个包中的所有类应该是共同重用的，如果重用了包的一个类，那么就要重用包中的所有类。重点是，相互之间没有紧密联系的类，不应该放在一个包中。否则，要么可能增加软件大小（apk这种），要么是一些不相关的类的更新，会导致所有依赖的地方被迫更新、验证，即使他们完全没有用这些类。 共同封闭原则CCP 一个包多所有类，应该对同一类变更是共同封闭的，也就是会为了同一个原因而修改，不应该包含多个引起变化的原因。一个需求变化到来时，应该将变化封闭在一个包中。（业务复杂，至少在修改问题时，不应该到处修改） 无环依赖原则 没啥好说的，包之间不能出现循环依赖，否则会出现无法构建、晨后综合征、测试困难、构建时间长等问题，可以用如下两个方式解决循环依赖：抵赖倒置、增加一个包，让两个模块都依赖新的包。

OLTP：联机事物处理 OLAP：联机分析处理 当今的数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。 OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数等问题。 OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。一般针对某些主题的历史数据进行分析，支持管理决策。 数据仓库标准上可以分为四层：ODS（临时存储层）、PDW（数据仓库层）、DM（数据集市层）、APP（应用层）。 ODS层： 为临时存储层，是接口数据的临时存储区域，为后一步的数据处理做准备。一般来说ODS层的数据和源系统的数据是同构的，主要目的是简化后续数据加工处理的工作。从数据粒度上来说ODS层的数据粒度是最细的。ODS层的表通常包括两类，一个用于存储当前需要加载的数据，一个用于存储处理完后的历史数据。历史数据一般保存3-6个月后需要清除，以节省空间。但不同的项目要区别对待，如果源系统的数据量不大，可以保留更长的时间，甚至全量保存； PDW层： 为数据仓库层，PDW层的数据应该是一致的、准确的、干净的数据

一、锁 1、锁的概述 InnoDB存储引擎中，事务的隔离性主要是由锁机制实现的。开发多用户的应用，很大的一个难点就在于并发访问：一方面既要最大程度地实现数据库的并发访问，另一方面又要确保每个用户能以一致的方式读取、修改数据，为此，我们需要锁机制。 锁机制是数据库系统区别于文件系统的另一个关键特性，锁机制用于管理对共享资源的并发访问，保证数据的完整性和一致性。这里的共享资源不仅仅是行数据，还包括缓冲池中的LRU列表，删除、添加、移动LRU列表中的元素时，有需要锁来保证一致性。 2、锁的类型 （1）共享/排他锁 MySQL提供了两种锁的粒度：行级锁、表级锁。一般而言，锁的粒度越小，并发度越高；锁用得越多，开销越大（锁的各种操作如获取锁、释放锁、检查锁状态等都会增加系统开销）。因此我们通常只锁定尽可能少的数据量，另外我们需要在锁开销和并发度之间找好平衡点。 InnoDB存储引擎提供两种行级锁： 共享锁（S Lock）：允许事务读一行数据； 排他锁（X Lock）：允许事务删除或更新一行数据。 如果事务T1已经获得行r的共享锁，那么事务T2可以立即获得行r的共享锁以读取数据（锁兼容）；如果事务T1已经获得行r的共享锁/排他锁，那么事务T2要想获得行r的排他锁/共享锁或排他锁必须等待事务T1释放锁（锁不兼容）。共享锁和排他锁均用在事务中，随着事务的结束而释放。 （2）意向锁