关系逻辑

这个系列原本打算写3篇，也就是说在上一篇文章中已经把老赵认为较合适的方法展现出来了，但事实上这个系列的计划已经扩展为8篇了——没错，翻了一倍不止，而最终是几篇现在我也无法断言。其实这也是我写不了书的原因之一。虽说唯一不变的就是变化，但是我变的太离谱了。不断写，不断出现新想法，不断变化。作为这个系列的第4篇，我们现在来对之前3篇文章进行一番阶段性总结。 阶段性总结本不在计划之内，不过似乎Actor模型这方面内容还不太受人关注，因此有的朋友也误解这系列文章想要解决的问题是什么。除了这方面的解释之外，我还会对之前提出的几种做法进行综合的对比，可以进一步了解整个演变过程的思路，为接下去的改变做铺垫——因为下次改变就涉及到多个方向，每个方向都是在一定程度上真正可用的方式。 我们究竟是要解决什么问题 Actor模型的本质已经被强调了无数遍：万物皆Actor。Actor之间只有发送消息这一种通信方式，例如，无论是管理员让工作者干活，还是工作者把成果交还给管理员，它们之间也要通过发送消息的方式来传递信息。这么做看似不如直接方法调用来的直接，但是由于大量的消息可以同时执行。同样，消息让Actor之间解耦，消息发出之后执行成功还是失败，需要耗费多少时间，只要没有消息传递回来，这一切都和发送方无关。Actor模型的消息传递形式简化了并行程序的开发，使开发人员无需在共享内存（确切地说，其实是共享“写”

API 接口中抛出的异常类型，有一系列的规则，代码在 ExceptionFilter 的 onResponse 中。 1. 如果是受检异常（非 Runtime ）就直接抛出 这是因为如果是受检异常，接口定义的 throws 中需要涵盖，调用端需要捕获该异常，该异常一定能访问到。 2. RuntimeException 并且接口 throws 时 这种情况下，接口指明抛出的异常，调用端也能获取该异常，因此可以直接抛出。 3. 异常和接口在一个 jar 包时 此时也可以直接抛出。 4. java. 和 javax. 前缀的异常时 这些都是 JDK 自带的，可以直接抛出。 5. dubbo RpcException 及其子类时 调用方也集成了 dubbo，因此可以直接抛出。 6. 其他情况 如果不满足前 5 个规则，就会被包装成统一的异常，导致异常信息变得冗长模糊。 7. 问题 dubbo 上述逻辑只在 A 调用 B 这种简单调用时有效，如果出现了 A->B->C，当 C 抛出异常时，B 能够正常接收，如果是 Runtime 类型的，B 没有处理时，会直接抛给 A，但是此时 B 抛出的异常和 B 接口没有任何关系，这就导致 B 在过滤器中进入第 6 种情况，导致 A 接收到的异常变得模糊。 如果系统基础包中定义了统一的异常类，在跨多次服务调用时仍然无法使用，想要避免问题只能从前 6

最近写的书中介绍到了在服务器上配置RAID卡，先发出来让大家参考一下。 一、RAID简介 RAID（Redundant Array of Independent Disks，独立磁盘冗余阵列）的基本思想就是把多个相对便宜的小磁盘组合起来，成为一个磁盘组， 使其性能达到甚至超过一个价格昂贵、容量巨大的磁盘。根据选择的冗余阵列模式不同，RAID比单盘有以下一个或多个方面的益处：增强数据整合度、增强容错功能、增加吞吐量或容量等特性。另外，磁盘组对于计算机来说， 看起来就像一个单独的磁盘或逻辑存储单元。常用的磁盘冗余阵列模式分为RAID-0、RAID-1、RAID-10、RAID-5、RAID-50。 RAID-0：这一技术有条带但是没有数据冗余。它提供了最好的性能但是不能容错。 RAID-1：这一个类型也称为磁盘镜像，至少由二个复制数据存储的驱动器组成。没有条带。因为任一驱动器能同时被读，读取性能被改良。写性能和单一磁盘存储相同。在多用户系统中，RAID-1 提供最好的性能和最好的容错。 RAID-5：数据以块为单位分布到各个硬盘上，RAID 5把数据和与其相对应的奇偶校验信息存储到组成RAID5的各个磁盘上，并且奇偶校验信息和相对应的数据分别存储于不同的磁盘上。当RAID5的一个磁盘数据损坏后，利用剩下的数据和相应的奇偶校验信息去恢复被损坏的数据。RAID

引言 磁盘一旦分区后，要更改分区的大小就很难了，也就是说在一个分区经过挂载之后，随着存储文件的增多，可用空间会越来越小，如果出现原先配置的磁盘空间不够的情况，那么是没有办法扩大分区的 既然直接使用吴丽娟的方式无法解决问题，那就只有靠分区的时候预估每个分区可能的后期用量，并划分足够的磁盘空间最大限度的延期情况的发生， 但是这个指标不治本 为了更好的使用磁盘空间，提高系统空间的可扩展性，此时要使用逻辑卷。 逻辑卷 是Logic Volume Manager 逻辑卷管理创建出来的设备，是linux操作系统可以认识的设备，事实上，LVM是介于磁盘裸设备和文件系统的中间层。 几个概念 物理卷 Physical Volume PV 。物理磁盘分区， /dev/sda /dev/sdb这种的，如果要用LVM来管理这个物理卷，可以使用fdisk将ID改为LVM可识别的值，（8e） 卷组 Volume Group VG， PV的集合 逻辑卷 Logic Volume LV。PV中划分出来的一块逻辑磁盘 关系： 首先创建一个或多个物理磁盘卷，物理卷按照相同或者不同的组名聚集成一个或多个物理卷组，而逻辑卷就是从某个物理卷组中抽象出来的一块磁盘空间。 制作逻辑卷 创建物理卷 pvcreate pvdisplay， 背景：虚拟机添加一个虚拟磁盘，添加完成后启动虚机，fdisk 查看 将/dev

GRBAC 项目地址： https://github.com/storyicon/grbac Grbac是一个快速，优雅和简洁的 RBAC 框架。它支持 增强的通配符 并使用 Radix 树匹配HTTP请求。令人惊奇的是，您可以在任何现有的数据库和数据结构中轻松使用它。 grbac的作用是确保指定的资源只能由指定的角色访问。请注意，grbac不负责存储鉴权规则和分辨“当前请求发起者具有哪些角色”，更不负责角色的创建、分配等。这意味着您应该首先配置规则信息，并提供每个请求的发起者具有的角色。 grbac将 Host 、 Path 和 Method 的组合视为 Resource ，并将 Resource 绑定到一组角色规则（称为 Permission ）。只有符合这些规则的用户才能访问相应的 Resource 。 读取鉴权规则的组件称为 Loader 。grbac预置了一些 Loader ，你也可以通过实现 func()(grbac.Rules，error) 来根据你的设计来自定义 Loader ，并通过 grbac.WithLoader 加载它。 1. 最常见的用例 2. 概念 2.1. Rule 2.2. Resource 2.3. Permission 2.4. Loader 3. 其他例子 3.1. gin && grbac.WithJSON 3.2. echo &&

  Protobuf应用广泛，尤其作为网络通讯协议最为普遍。本文将详细描述几个让人眼前一亮的protobuf协议设计，对准备应用或已经应用protobuf的开发者会有所启发，甚至可以直接拿过去用。 这里描述的协议设计被用于生产环境的即时通讯、埋点数据采集、消息推送、redis和mysql数据代理。   Bwar从2013年开始应用protobuf，2014年设计了用于mysql数据代理的protobuf协议，2015年设计了用于即时通讯的protobuf协议。高性能C++ IoC网络框架Nebula https://github.com/Bwar/Nebula 把这几个protobuf协议设计应用到了极致。 1. TCP通讯协议设计   本协议设计于2015年，用于一个生产环境的IM和埋点数据采集及实时分析，2016年又延伸发展了基于protobuf3的版本并用于开源网络框架 Nebula 。基于protobuf2和protobuf3的有较少差别，这里分开讲解两个版本的协议设计。 1.1. protobuf2.5版Msg   2015年尚无protobuf3的release版本，protobuf2版本的fixed32类型是固定占用4个字节的，非常适合用于网络通讯协议设计。Bwar设计用于IM系统的协议包括两个protobuf message：MsgHead和MsgBody

1. 概要   本文描述一个通过C++可变参数模板实现C++反射机制的方法。该方法非常实用，在 Nebula 高性能网络框架中大量应用，实现了非常强大的动态加载动态创建功能。   C++11的新特性--可变模版参数（variadic templates）是C++11新增的最强大的特性之一，它对参数进行了高度泛化，它能表示0到任意个数、任意类型的参数。关于可变参数模板的原理和应用不是本文重点，不过通过本文中的例子也可充分了解可变参数模板是如何应用的。   熟悉Java或C#的同学应该都知道反射机制，很多有名的框架都用到了反射这种特性，简单的理解就是只根据类的名字（字符串）创建类的实例。 C++并没有直接从语言上提供反射机制给我们用，不过无所不能的C++可以通过一些trick来实现反射。 Bwar 也是在开发Nebula框架的时候需要用到反射机制，在网上参考了一些资料结合自己对C++11可变参数模板的理解实现了C++反射。 2. C++11之前的模拟反射机制实现    Nebula 框架是一个高性能事件驱动通用网络框架，框架本身无任何业务逻辑实现，却为快速实现业务提供了强大的功能、统一的接口。业务逻辑通过从Nebula的Actor类接口编译成so动态库，Nebula加载业务逻辑动态库实现 各种功能Server ，开发人员只需专注于业务逻辑代码编写，网络通信、定时器、数据序列化反序列化

内容来源：宜信技术学院第4期技术沙龙-线上直播|宜信微服务任务调度平台建设实践 主讲人：宜信高级架构师&开发平台负责人 梁鑫 导读：如今，无论是互联网应用还是企业级应用，都充斥着大量的批处理任务，常常需要一些任务调度系统帮助我们解决问题。随着微服务化架构的逐步演进，单体架构逐渐演变为分布式、微服务架构。 在此背景下，很多之前的任务调度平台已经不能满足业务系统的需求，于是出现了一些基于分布式的任务调度平台。这些平台各有其特点，但也各有不足之处，比如不支持任务编排、与业务高耦合、不支持跨平台等问题，不是非常符合公司的需求，因此我们开发了微服务任务调度平台（SIA-TASK）。本次分享主要围绕SIA平台展开，包括研发背景设计思路和技术架构，以及如何支持业务方。 一、SIA-TASK的产生 1.1 背景 无论是互联网应用还是企业级应用，都充斥着大量的批处理任务，常常需要一些任务调度系统帮助我们解决问题。随着微服务化架构的逐步演进，单体架构逐渐演变为分布式、微服务架构。 在这样的背景下，很多之前的任务调度平台或组件已经不能满足业务系统的需求，于是出现了一些基于分布式的任务调度平台。这些平台各有其特点，但也各有不足之处，比如不支持任务编排、与业务高耦合、不支持跨平台等问题。 1.2 种类 按照任务与时间的关系，我们把批处理任务分成三类，飞机型、地铁型、公共汽车型。 飞机型是指每年/月/周

逻辑判断在编程中是非常重要的，大量的复杂程序在根本上都是建立在“真”与“假”的基本逻辑上。 而bool所表示的就是这种最单纯最本质的True/False,真与假，是与非。 举个例子： a = 1 <３ print(a) b = 1 a = 4 print(b > a) 　　通过用“> ”"<"来比较两个数值，我们就得到了一个bool值。这个bool值的真假取决于比较的结果。 “>”"<"　在编程语言中被称为 比较（关系）运算符， 常用的比较（关系）运算符包括： > : 大于 < : 小于 >= : 大于等于 <= : 小于等于 == : 等于 != : 不等于 还有一种逻辑运算符： not : 逻辑"非"。如果x 为True,则not x 为 False and：逻辑”与“。如果x 为True, 且y 为True，则X and y为True or : 逻辑”或“。如果x、y中至少有一个为True,则X or y为True 来源： https://www.cnblogs.com/ABLIBU/p/11314519.html

前言: Qualcomm MSM Interface,作用用于AP和BP侧的交互，通俗说法就是让设备终端TE（可以是手机，PDA，计算机） 对高通BP侧的AMSS系统进行操作，如调用函数，读取数据，设置其中的NV项等。 QMI的核心称之为QMI框架（QMI Framework），其主要功能包括以下3点： 1,连接MSM模块和设备终端，提供一个正交的控制和数据通道。在QMI的消息用有两种定义，一种是 QMIControl Message,另一种是QMI DataMessage，支持这两种消息并发，不会互相干扰导致出错。 2,列举一系列的枚举逻辑设备，提供给连接使用。QMI机制类似于一个服务器机制，有相应的client端 和services端，对应于QMI的control point和service。在AP向BP发送请求时，AP作为client端，当AP 接收BP侧返回的响应时，AP作为services端。QMI包含了一系列的QMI Service，例如nas,voice,wds等， 这些不同的services相当于不同逻辑设备，给不同的app调用。 3,QMI有相应的消息和消息的协议，设备终端就是通过这些消息来访问AMSS。对于不同的qmi消息， 消息长度不一样，可自己定义消息长度，不同的qmi消息，消息格式是相同的。 上图是QMIFramework的一个软件结构图。 从图中可以看出