Inbox

“UART” 串口通信 UART 异步收发传输器(Universal Asynchronous Receiver/Transmitter)，通常称作UART，是一种异步收发传输器。 首先先来介绍以下同步和异步通信，同步是指，发送方发出数据后，等接收方发回响应以后才发下一个数据包的通讯方式；异步是指，发送方发出数据后，不等接收方发回响应，接着发送下个数据包的通讯方式。换句话说，同步通信是阻塞方式，异步通信是非阻塞方式。在常见通信总线协议中，I2C，SPI属于同步通信而UART属于异步通信。同步通信的通信双方必须先建立同步，即双方的时钟要调整到同一个频率，收发双方不停地发送和接收连续的同步比特流。异步通信在发送字符时，发送端可以在任意时刻开始发送字符，所以，在UART通信中，数据起始位和停止位是必不可少的。 硬件层 常用RS-232标准，这里不详细解释，主要是对应设备的Tx线和Rx线要对应正确。 协议层 协议层中，规定了数据包的内容，它由起始位、主体数据、校验位以及停止位组成，通信双方的数据包格式要约定一致才能正常收发数据 。 波特率: 异步通信中由于没有时钟信号，所以2个通信设备需约定好波特率，常见的有4800、9600、115200等。 通信的起始和停止信号: 串口通信的一个数据包从起始信号开始，知道停止信号结束。数据包的起始信号由一个逻辑0的数据位表示，而数据包的停止信号可由0.5、1、1.5或2个逻辑1的数据位表示，只要双方约定一致即可。 有效数据: 在数据包的起始位之后紧接着的就是要传输的主体数据内容，也称为有效数据，有效数据的长度常被约定为8位或9位长。 数据校验: 在有效数据之后，有一个可选的数据校验位。由于数据通信相对容易受到外部干扰导致传输数据出现偏差，可以在传输过程加上校验位来解决这个问题。校验方法有奇校验(odd)、偶校验(even)、0校验(space)、1校验(mark)以及无校验(noparity)。 奇校验要求有效数据和校验位中"1"的个数为奇数，比如一个 8 位长的有效数据为: 01101001，此时总共有 4 个"1"，为达到奇校验效果，校验位为"1"，最后传输的数据将是 8 位的有效数据加上 1 位的校验位总共 9 位。偶校验与奇校验要求刚好相反，要求帧数据和校验位中"1"的个数为偶数，比如数据帧: 11001010，此时数据帧"1"的个数为 4 个，所以偶校验位为"0"。0 校验是不管有效数据中的内容是什么，校验位总为"0"，1 校验是校验位总为"1"。 https://zhuanlan.zhihu.com/p/136806005

“uclibc, glibc” uClibc 和Glibc 并不相同,两者有许多不同之处,而且以下不同有可能给你带来一些问题. uClibc比Glibc小,虽然uClibc和Glibc在已有的接口上是兼容的,而且采用uClibc编译应用程序比采用Glibc编译应用程序要更方便,但是uClibc并没有包括Glibc中的所有接口实现,因此有些应用可能在uClibc中不能编译。 uClibc在可配置性上比Glibc要好。 uClibc 并不能保证发布的库二进制兼容旧版本uClibc库。当一个新的版本uClibc库被发布,则可能需要也可能不需要重新编译应用程序。 在Glibc中调用malloc(0),将返回一个有效的指针,然而在uClibc中调用malloc(0),则返回NULL指针。根据在SuSv3中关于malloc(0)的行为的定义,两个库的实现都是正确的。对于调用relloc(NULL,0),两个库的实现也不同。个人感觉Glibc的如此实现不是特别安全。 Glibc中malloc的实现可以通过MALLOC_CHECK_ 环境变量调节。这个方法主要用于malloc调试。这些扩展的malloc调试特性在uClibc中是不可用的。在Linux上有许多有些的malloc调试功能的库(如: dmalloc,electric fence,valgrind等)比Glibc中的扩展的malloc调试功能更好用。因此uClibc中去掉这些功能特性并不会有多打损失。 uClibc没有提供用于数据接口的库(libdb)。 uClibc不支持NSS(/lib/libnss_*),在这方面Glibc更容易支持不同方式的认证和DNS解析。uClibc仅仅支持采用flat口令文件或者shadow口令文件存储授权信息。如果需要比这些更复杂的的授权,可以编译安装pam。 uClibc中的libresolv库仅仅是一个桩。Glibc的libresolv库中的部分并不是全部的功能uClibc都提供,许多函数都没有实现。 提供网络信息服务支持(NIS)libnsl库(最初被称为黄页YP),被SUN扩展为发明为RPC并用于网络共享Unix口令文件 。个人认为NIS是一个令人厌恶的东西并应该使用。因此,在实现相同的功能情况下采用ldap比NIS更有效。uClibc虽然提供一个桩libnsl,但并不支持NIS。我们因此也不提供在Glibc下提供的位于/usr/include/rpcsvc里的头文件。 uClibc的区域支持并不是100%的完全。正在这方面努力 uClibc的数据功能函数库内部仅仅支持long double,设置对于long double的支持也是非常有限。与此对应的只实现了较少的数学函数。如果应用程序采用double类型,则会程序会运行得较好。 uClibc的libcrpt库不支持可重入crypt_r,setkey_r和encrypt_r,因为这些也不是SuSv3所规定的。 uClibc直接采用内核的数据类型去定义大多数透明的数据类型。 uClibc支持采用linux内核结构特有的结构体"struct stat"。 uClibc的运行时库librt当前缺少aio接口、全部的时钟接口和共享内存接口(仅仅实现定时器接口和消息队列接口) 版权声明: 本文为CSDN博主「zengwh」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。 原文链接: https://blog.csdn.net/zengwh/article/details/1482418

“UPS” 后备式UPS 平时处于蓄电池充电状态， 在停电时逆变器紧急切换到工作状态，将电池提供的直流电转变为稳定的交流电输出，因此后备式UPS也被称为离线式UPS。后备式UPS电源的优点是: 运行效率高、噪音低、价格相对便宜，主要适用于市电波动不大，对供电质量要求不高的场合，比较适合家庭使用。然而这种UPS存在一个切换时间问题，因此不适合用在关键性的供电不能中断的场所。不过实际上这个切换时间很短，一般介于2 至10毫秒，而计算机本身的交换式电源供应器在断电时应可维持10 毫秒左右，所以个人计算机系统一般不会因为这个切换时间而出现问题。后备式UPS一般只能持续供电几分钟到几十分钟，主要是让您有时间备份数据，并尽快结束手头工作，其价格也较低。对不是太关键的电脑应用，比如个人家庭用户，就可配小功率的后备式UPS。 在线式UPS 这种UPS一直使其逆变器处于工作状态，它首先通过电路将外部交流电转变为直流电，再通过高质量的逆变器将直流电转换为高质量的正弦波交流电输出给计算机。在线式UPS在供电状况下的主要功能是稳压及防止电波干扰； 在停电时则使用备用直流电源 (蓄电池组) 给逆变器供电。由于逆变器一直在工作，因此不存在切换时间问题，适用于对电源有严格要求的场合。在线式UPS不同于后备式的一大优点是供电持续长，一般为几个小时， 也有大到十几个小时的， 它的主要功能是可以让您在停电的情况可像平常一样工作，显然，由于其功能的特殊，价格也明显要贵一大截。这种在线式UPS比较适用于计算机、交通、银行、证券、通信、医疗、工业控制等行业，因为这些领域的电脑一般不允许出现停电现象。 在线互动式UPS 这是一种智能化的UPS，所谓在线互动式UPS，是指在输入市电正常时， UPS的逆变器处于反向工作 (即整流工作状态) ，给电池组充电；在市电异常时逆变器立刻转为逆变工作状态，将电池组电能转换为交流电输出，因此在线互动式UPS也有转换时间。同后备式UPS相比，在线互动式UPS的保护功能较强，逆变器输出电压波形较好，一般为正弦波，而其最大的优点是具有较强的软件功能，可以方便地上网，进行UPS的远程控制和智能化管理。可自动侦测外部输入电压是否处于正常范围之内， 如有偏差可由稳压电路升压或降压， 提供比较稳定的正弦波输出电压。而且它与计算机之间可以通过数据接口 (如RS-232 串口) 进行数据通讯，通过监控软件，用户可直接从电脑屏幕上监控电源及UPS状况，简化、方便管理工作，并可提高计算机系统的可靠性。这种UPS集中了后备式UPS效率高和在线式UPS供电质量高的优点，但其稳频特性能不是十分理想，不适合做常延时的UPS电源。 https://zhuanlan.zhihu.com/p/45168295 灵敏度 所谓灵敏度，就是指UPS对电网的敏感程度，灵敏度越高，对电网越敏感，对电网质量要求也就越高。对于电网质量较差的地方或使用发电机的地方，如果灵敏度高，可能会造成UPS一直在市电供电和电池供电状态间来回切换，或导致UPS一直工作在电池状态，对此，可适当降低灵敏度，以期在这种供电环境中UPS能正常工作，节省电池电量，为负载提供长延时保护。

“user design” https://segmentfault.com/q/1010000005013911

“xorm” generate golang code /home/wiloon/workspace/my-projects/reverse/reverse -f custom-business.yml https://gitea.com/xorm/xorm https://gitea.com/xorm/reverse https://studygolang.com/articles/27223

“中断, interrupts” IRQ: Interrupt ReQuest, 中断请求 IDT，Interrupt Descriptor Table，中断描述符表 中断/interrupts 中断指当出现需要时，CPU暂时停止当前程序的执行转而执行处理新情况的程序和执行过程。即在程序运行过程中，系统出现了一个必须由CPU立即处理的情况，此时，CPU暂时中止程序的执行转而处理这个新的情况的过程就叫做中断。 为什么需要中断 如果让内核定期对设备进行轮询，以便处理设备请求，那会做很多无用功，因为外设的处理速度一般慢于CPU，而CPU不能一直等待外部事件。所以能让设备在需要内核时主动通知内核，会是一个聪明的方式，这便是中断。 https://blog.csdn.net/oathevil/article/details/6007655 中断分类 外中断 由 CPU 执行指令以外的事件引起，如 I/O 完成中断，表示设备输入/输出处理已经完成，处理器能够发送下一个输入/输出请求。此外还有时钟中断、控制台中断等。 异常 由 CPU 执行指令的内部事件引起，如非法操作码、地址越界、算术溢出等。 陷入 在用户程序中使用系统调用 中断是什么 中断的汉语解释是半中间发生阻隔、停顿或故障而断开。那么，在计算机系统中，我们为什么需要"阻隔、停顿和断开"呢？ 举个日常生活中的例子，比如说我正在厨房用煤气烧一壶水，这样就只能守在厨房里，苦苦等着水开——如果水溢出来浇灭了煤气，有可能就要发生一场灾难了。等啊等啊，外边突然传来了惊奇的叫声"怎么不关水龙头？“于是我惭愧的发现，刚才接水之后只顾着抱怨这份无聊的差事，居然忘了这事，于是慌慌张张的冲向水管，三下两下关了龙头，声音又传到耳边，“怎么干什么都是这么马虎？"。伸伸舌头，这件小事就这么过去了，我落寞的眼神又落在了水壶上。 门外忽然又传来了铿锵有力的歌声，我最喜欢的古装剧要开演了，真想夺门而出，然而，听着水壶发出"咕嘟咕嘟"的声音，我清楚: 除非等到水开，否则没有我享受人生的时候。 这个场景跟中断有什么关系呢？ 如果说我专心致志等待水开是一个过程的话，那么叫声、电视里传出的音乐不都让这个过程"半中间发生阻隔、停顿或故障而断开"了吗？这不就是活生生的"中断"吗？ 在这个场景中，我是唯一具有处理能力的主体，不管是烧水、关水龙头还是看电视，同一个时间点上我只能干一件事情。但是，在我专心致志干一件事情时，总有许多或紧迫或不紧迫的事情突然出现在面前，都需要去关注，有些还需要我停下手头的工作马上去处理。只有在处理完之后，方能回头完成先前的任务，“把一壶水彻底烧开！” 中断机制不仅赋予了我处理意外情况的能力，如果我能充分发挥这个机制的妙用，就可以"同时"完成多个任务了。回到烧水的例子，实际上，无论我在不在厨房，煤气灶总是会把水烧开的，我要做的，只不过是及时关掉煤气灶而已，为了这么一个一秒钟就能完成的动作，却让我死死地守候在厨房里，在10分钟的时间里不停地看壶嘴是不是冒蒸气，怎么说都不划算。我决定安下心来看电视。当然，在有生之年，我都不希望让厨房成为火海，于是我上了闹钟，10分钟以后它会发出"尖叫”，提醒我炉子上的水烧开了，那时我再去关煤气也完全来得及。我用一个中断信号——闹铃——换来了10分钟的欢乐时光，心里不禁由衷地感叹: 中断机制真是个好东西。 正是由于中断机制，我才能有条不紊地"同时"完成多个任务，中断机制实质上帮助我提高了并发"处理"能力。它也能给计算机系统带来同样的好处: 如果在键盘按下的时候会得到一个中断信号，CPU就不必死守着等待键盘输入了；如果硬盘读写完成后发送一个中断信号，CPU就可以腾出手来集中精力"服务大众"了——无论是人类敲打键盘的指尖还是来回读写介质的磁头，跟CPU的处理速度相比，都太慢了。没有中断机制，就像我们苦守厨房一样，计算机谈不上有什么并行处理能力。 跟人相似，CPU也一样要面对纷繁芜杂的局面——现实中的意外是无处不在的——有可能是用户等得不耐烦，猛敲键盘；有可能是运算中碰到了0除数；还有可能网卡突然接收到了一个新的数据包。这些都需要CPU具体情况具体分析，要么马上处理，要么暂缓响应，要么置之不理。无论如何应对，都需要CPU暂停"手头"的工作，拿出一种对策，只有在响应之后，方能回头完成先前的使命，“把一壶水彻底烧开！” 先让我们感受一下中断机制对并发处理带来的帮助。 让我们用程序来探讨一下烧水问题，如果没有"中断” (注意，我们这里只是模仿中断的场景，实际上是用异步事件——消息——处理机制来展示中断产生的效果。毕竟，在用户空间没有办法与实际中断产生直接联系，不过操作系统为用户空间提供的异步事件机制，可以看作是模仿中断的产物) ，设计如下: void StayInKitchen() { bool WaterIsBoiled = false; while ( WaterIsBoiled != true ) { bool VaporGavenOff = false; if (VaporGavenOff ) WaterIsBoiled = true; else WaterIsBoiled = false; } // 关煤气炉 printf("Close gas oven./n"); // 一切安定下来，终于可以看电视了，10分钟的宝贵时间啊，逝者如斯夫… watching_tv(); return; } 可以看出，整个流程如同我们前面描述的一样，所有工作要顺序执行，没有办法完成并发任务。 ...

“主从模式 VS 哨兵sentinel模式 VS Redis cluster模式” 主从模式 (redis2.8版本之前的模式) 、 哨兵 sentinel模式 (redis2.8及之后的模式) 、 redis cluster模式 (redis3.0版本之后) 主从模式原理 同MySQL主从复制的原因一样，Redis虽然读取写入的速度都特别快，但是也会产生读压力特别大的情况。为了分担读压力，Redis支持主从复制，Redis的主从结构可以采用一主多从或者级联结构，Redis主从复制可以根据是否是全量分为全量同步和增量同步。下图为级联结构。 优点: 解决数据备份问题 做到读写分离，提高服务器性能 缺点: 每个客户端连接redis实例的时候都是指定了ip和端口号的，如果所连接的redis实例因为故障下线了，而主从模式也没有提供一定的手段通知客户端另外可连接的客户端地址，因而需要手动更改客户端配置重新连接 主从模式下，如果主节点由于故障下线了，那么从节点因为没有主节点而同步中断，因而需要人工进行故障转移工作 无法实现动态扩容 sentinel 哨兵模式 Sentinel (哨兵) 是 Redis 的高可用性解决方案: 由一个或多个 Sentinel实例组成的Sentinel系统可以监视任意多个主服务器， 以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器。 优点 Master 状态监测 如果 Master 异常，则会进行 Master-slave 转换，将其中一个 Slave 作为 Master，将之前的 Master 作为 Slave Master-Slave 切换后，master_redis.conf、slave_redis.conf 和 sentinel.conf 的内容都会发生改变，即 master_redis.conf 中会多一行 slaveof 的配置，sentinel.conf 的监控目标会随之调换 缺点: 如果是从节点下线了，sentinel 是不会对其进行故障转移的，连接从节点的客户端也无法获取到新地可用从节点 无法实现动态扩容 cluster 模式 在这个图中，每一个蓝色的圈都代表着一个redis的服务器节点。它们任何两个节点之间都是相互连通的。客户端可以与任何一个节点相连接，然后就可以访问集群中的任何一个节点。对其进行存取和其他操作。 一般集群建议搭建三主三从架构，三主提供服务，三从提供备份功能。每一个节点都存有这个集群所有主节点以及从节点的信息。 它们之间通过互相的ping-pong判断是否节点可以连接上。如果有一半以上的节点去ping一个节点的时候没有回应，集群就认为这个节点宕机了，然后去连接它的备用节点。如果某个节点和所有从节点全部挂掉，我们集群就进入faill状态。还有就是如果有一半以上的主节点宕机，那么我们集群同样进入发力了状态。这就是我们的redis的投票机制，具体原理如下图所示: (1)投票过程是集群中所有master参与,如果半数以上master节点与master节点通信超时(cluster-node-timeout),认为当前master节点挂掉. (2):什么时候整个集群不可用(cluster_state:fail)? ...

“字体 , 编程字体, 等宽字体” ubunti install 微软雅黑 sudo apt-get install ttf-mscorefonts-installer # 更新字体缓存 sudo fc-cache -f -v 编程字体, 等宽字体 对于程序员来说,好的字体应该满足的基本条件: 字母和数字易于分辨,如: 英文字母 o 和 阿拉伯数字 0, 或者 英文字母 l 和 阿拉伯数字 1 ,两个单引号 ’’ 和双引号 “. 字体等宽,保持对齐,美观漂亮 免费开源 Source Code Pro 是 Adobe 公司号称最佳的编程字体。而且还是开源的。 它非常适合用于阅读代码,支持 Linux、Mac OS X 和 Windows 等操作系统,而且无论商业或个人都可以免费使用。 作者: jingr1 链接: https://www.jianshu.com/p/1d5e1aaeb3f6 来源: 简书 著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 https://www.archlinux.org/packages/extra/any/adobe-source-code-pro-fonts/ jetbrain 字体 JetBrain Mono yay -S ttf-jetbrains-mono FiraCode https://github.com/tonsky/FiraCode 等宽字体 status { /width: auto;/ ...

宾语从句（Object Clause） 在句子中起宾语作用的从句叫做宾语从句.宾语从句分为三类:动词的宾语从句,介词的宾语从句和形容词的宾语从句. 时态： 1.主句用一般现在时，从句可用任意时态。 2.主句用过去时，从句用过去某个时态。 3.主句用过去时，从句是真理时，只用一般现在时。 一、宾语从句的连接词 从属连词 连接宾语从句的从属连词主要有that,if,whether. that引导表示陈述句的宾语从句,而if和whether引导表示“是否”的宾语从句. He told me that he would go to the college the next year 他告诉我他下一年上大学. I don’t know if there will be a bus any more. 我不知道是否还会有公交车. Nobody knew whether he could pass the exam. 没人知道他是否会通过考试. 连接代词 连接代词主要有who, whom ,whose ,what ,whoever ,whomever ,whosever, whatever, whichever等. 关系代词what引导 连接代词一般指疑问,但what, whatever除了指疑问外,也可以指陈述. Do you know who has won Red Alert game? 你知道谁赢了这一局红警游戏吗? I don’t know whom you should depend on. ...

“服务器三大体系 SMP、NUMA、MPP” https://blog.csdn.net/ZhipingXi/article/details/78133096 服务器三大体系 SMP、NUMA、MPP zhipingxi 2017-09-29 13:50:15 2236 收藏 5 分类专栏: Operating System 文章标签: 服务器 系统架构 numa smp mpp 系统架构来看，目前的商用服务器大体可以分为三类 对称多处理器结构(SMP: Symmetric Multi-Processor)； 非一致存储访问结构(NUMA: Non-Uniform Memory Access)； 海量并行处理结构(MPP: Massive Parallel Processing)； 共享存储型多处理机有两种模型 均匀存储器存取 (Uniform-Memory-Access，简称UMA) 模型 非均匀存储器存取 (Nonuniform-Memory-Access，简称NUMA) 模型 SMP(Symmetric Multi-Processor) 所谓对称多处理器结构，是指服务器中多个CPU对称工作，无主次或从属关系。各CPU共享相同的物理内存，每个 CPU访问内存中的任何地址所需时间是相同的，因此SMP也被称为一致存储器访问结构(UMA: Uniform Memory Access)。对SMP服务器进行扩展的方式包括增加内存、使用更快的CPU、增加CPU、扩充I/O(槽口数与总线数)以及添加更多的外部设备(通常是磁盘存储)。 SMP服务器的主要特征是共享，系统中所有资源(CPU、内存、I/O等)都是共享的。也正是由于这种特征，导致了SMP服务器的主要问题，那就是它的扩展能力非常有限。对于SMP服务器而言，每一个共享的环节都可能造成SMP服务器扩展时的瓶颈，而最受限制的则是内存。由于每个CPU必须通过相同的内存总线访问相同的内存资源，因此随着CPU数量的增加，内存访问冲突将迅速增加，最终会造成CPU资源的浪费，使 CPU性能的有效性大大降低。实验证明，SMP服务器CPU利用率最好的情况是2至4个CPU。 图1.SMP服务器CPU利用率状态 NUMA(Non-Uniform Memory Access) 由于SMP在扩展能力上的限制，人们开始探究如何进行有效地扩展从而构建大型系统的技术，NUMA就是这种努力下的结果之一。利用NUMA技术，可以把几十个CPU(甚至上百个CPU)组合在一个服务器内。其CPU模块结构如图2所示: 图2.NUMA服务器CPU模块结构 NUMA服务器的基本特征是具有多个CPU模块，每个CPU模块由多个CPU(如4个)组成，并且具有独立的本地内存、I/O槽口等。由于其节点之间可以通过互联模块(如称为Crossbar Switch)进行连接和信息交互，因此每个CPU可以访问整个系统的内存(这是NUMA系统与MPP系统的重要差别)。显然，访问本地内存的速度将远远高于访问远地内存(系统内其它节点的内存)的速度，这也是非一致存储访问NUMA的由来。由于这个特点，为了更好地发挥系统性能，开发应用程序时需要尽量减少不同CPU模块之间的信息交互。利用NUMA技术，可以较好地解决原来SMP系统的扩展问题，在一个物理服务器内可以支持上百个CPU。比较典型的NUMA服务器的例子包括HP的Superdome、SUN15K、IBMp690等。 但NUMA技术同样有一定缺陷，由于访问远地内存的延时远远超过本地内存，因此当CPU数量增加时，系统性能无法线性增加。如HP公司发布Superdome服务器时，曾公布了它与HP其它UNIX服务器的相对性能值，结果发现，64路CPU的Superdome (NUMA结构)的相对性能值是20，而8路N4000(共享的SMP结构)的相对性能值是6.3。从这个结果可以看到，8倍数量的CPU换来的只是3倍性能的提升。 MPP(Massive Parallel Processing) 和NUMA不同，MPP提供了另外一种进行系统扩展的方式，它由多个SMP服务器通过一定的节点互联网络进行连接，协同工作，完成相同的任务，从用户的角度来看是一个服务器系统。其基本特征是由多个SMP服务器(每个SMP服务器称节点)通过节点互联网络连接而成，每个节点只访问自己的本地资源(内存、存储等)，是一种完全无共享(Share Nothing)结构，因而扩展能力最好，理论上其扩展无限制，目前的技术可实现512个节点互联，数千个CPU。目前业界对节点互联网络暂无标准，如 NCR的Bynet，IBM的SPSwitch，它们都采用了不同的内部实现机制。但节点互联网仅供MPP服务器内部使用，对用户而言是透明的。 在MPP系统中，每个SMP节点也可以运行自己的操作系统、数据库等。但和NUMA不同的是，它不存在异地内存访问的问题。换言之，每个节点内的CPU不能访问另一个节点的内存。节点之间的信息交互是通过节点互联网络实现的，这个过程一般称为数据重分配(Data Redistribution)。 但是MPP服务器需要一种复杂的机制来调度和平衡各个节点的负载和并行处理过程。目前一些基于MPP技术的服务器往往通过系统级软件(如数据库)来屏蔽这种复杂性。举例来说，NCR的Teradata就是基于MPP技术的一个关系数据库软件，基于此数据库来开发应用时，不管后台服务器由多少个节点组成，开发人员所面对的都是同一个数据库系统，而不需要考虑如何调度其中某几个节点的负载。 NUMA与MPP的区别 ...

“炼妖壶” https://zhuanlan.zhihu.com/p/50584002

“相互转换逗号分隔的字符串和List” https://blog.csdn.net/yywusuoweile/article/details/50315377 将逗号分隔的字符串转换为List 方法 1: 利用JDK的Arrays类 String str = “a,b,c”; List result = Arrays.asList(str.split(",")); 方法 2: 利用Guava的Splitter String str = “a, b, c”; List result = Splitter.on(",").trimResults().splitToList(str); 方法 3: 利用Apache Commons的StringUtils (只是用了split) String str = “a,b,c”; List result = Arrays.asList(StringUtils.split(str,",")); 方法 4: 利用Spring Framework的StringUtils String str = “a,b,c”; List str = Arrays.asList(StringUtils.commaDelimitedListToStringArray(str)); 将List转换为逗号分隔符 方法 1: 利用JDK (好像没有很好的方法，需要一步一步实现) ...

“线程模型” 多线程模型: 一对一模型、多对一模型和多对多模型 迄今为止，我们只是泛泛地讨论了线程。不过，有两种不同方法来提供线程支持: 用户层的用户线程或内核层的内核线程。 用户线程位于内核之上，它的管理无需内核支持；而内核线程由操作系统来直接支持与管理。几乎所有的现代操作系统，包括 Windows、Linux、Mac OS X 和 Solaris，都支持内核线程。 最终，用户线程和内核线程之间必然存在某种关系。本节研究三种常用的建立这种关系的方法: 多对一模型、一对一模型和多对多模型。 多对一模型 多对一模型 多对一模型 (图 1) 映射多个用户级线程到一个内核线程。 线程管理是由用户空间的线程库来完成的，因此效率更高。不过，如果一个线程执行阻塞系统调用，那么整个进程将会阻塞。再者，因为任一时间只有一个线程可以访问内核，所以多个线程不能并行运行在多处理核系统上。 Green threads 线程库为 Solaris 所采用，也为早期版本的 Java 所采纳，它就使用了多对一模型。然而，现在几乎没有系统继续使用这个模型，因为它无法利用多个处理核。 一对一模型 一对一模型 图 2 一对一模型 一对一模型 (图 2) 映射每个用户线程到一个内核线程。 该模型在一个线程执行阻塞系统调用时，能够允许另一个线程继续执行，所以它提供了比多对一模型更好的并发功能；它也允许多个线程并行运行在多处理器系统上。 这种模型的唯一缺点是，创建一个用户线程就要创建一个相应的内核线程。由于创建内核线程的开销会影响应用程序的性能，所以这种模型的大多数实现限制了系统支持的线程数量。Linux，还有 Windows 操作系统的家族，都实现了一对一模型。 多对多模型 多对多模型 图 3 多对多模型 多对多模型 (图 3) 多路复用多个用户级线程到同样数量或更少数量的内核线程。内核线程的数量可能与特定应用程序或特定机器有关 (应用程序在多处理器上比在单处理器上可能分配到更多数量的线程) 。 现在我们考虑一下这些设计对并发性的影响。虽然多对一模型允许开发人员创建任意多的用户线程，但是由于内核只能一次调度一个线程，所以并未增加并发性。虽然一对一模型提供了更大的并发性，但是开发人员应小心，不要在应用程序内创建太多线程 (有时系统可能会限制创建线程的数量) 。 多对多模型没有这两个缺点: 开发人员可以创建任意多的用户线程，并且相应内核线程能在多处理器系统上并发执行。而且，当一个线程执行阻塞系统调用时，内核可以调度另一个线程来执行。 多对多模型的一种变种仍然多路复用多个用户级线程到同样数量或更少数量的内核线程，但也允许绑定某个用户线程到一个内核线程。这个变种，有时称为双层模型 (图 4) 。 双层模型 图 4 双层模型 Solaris 操作系统在第 9 版以前支持这种双层模型；但从第 9 版后，就使用了一对一模型。

“限流、熔断与降级” 限流 Rate Limiting 限流是从系统的流量入口考虑，从进入的流量上进行限制，达到保护系统的作用 是指需要限制并发/请求量的场景 (如秒杀等) ，通过限流保护服务免受雪崩之灾。 计数器 多少次每秒/每分/每天，根据作用范围的不同，计算器可以分为单机计数器即Local Counter (每个机器都有自己的计数器) 和全局计数器也就是分布式计数器即Global Counter (所有机器公有一个计数器阈值) 令牌桶 令牌桶算法是网络流量整形 (Traffic Shaping) 和速率限制 (Rate Limiting) 中最常使用的一种算法。典型情况下，令牌桶算法用来控制发送到网络上的数据的数目，并允许突发数据的发送。 令牌桶算法的原理是系统会以一个恒定的速度往桶里放入令牌，而如果请求需要被处理，则需要先从桶里获取一个令牌，当桶里没有令牌可取时，则拒绝服务。 漏桶 漏桶算法思路很简单，水 (请求) 先进入到漏桶里，漏桶以一定的速度出水，当水流入速度过大会直接溢出，可以看出漏桶算法能强行限制数据的传输速率。 方法 优点 缺点 计数器 简单方便 存在一下子被刷完计数器的情况 令牌桶 可以处理瞬间突发的流量 ~ 漏桶 限制请求的平均速率 不能处理瞬间流量的情况，当流量把漏桶装满后，大部分的请求都会被丢弃掉 熔断 Circuit Breaker 主调熔断 主调熔断是熔断的主要场景，在微服务中是结合服务注册和发现组件来使用的。主调通过服务发现组件来获取被调的实例，如果主调的失败达到了一个阈值，服务发现组件会熔断被调的实例。 被调熔断 被调熔断，被调实例获取当前的实例负载情况，如果cpu/内存/io 等超过了一定的阈值，那么就会触发熔断，将抛弃进来的请求。此时熔断和限流比较像，一个是基于负载情况，一个是根据配置的阈值情况。 降级 降级，是从系统内部的平级服务或者业务的维度考虑，流量大了，可以干掉一些，保护其他功能正常使用。 降级也就是服务降级，当我们的服务器压力剧增为了保证核心功能的可用性 ，而选择性的降低一些功能的可用性，或者直接关闭该功能。这就是典型的丢车保帅了。当服务暂时不可用或者影响到核心流程时，需要待高峰或者问题解决后再打开。通过降级实现部分可用、有损服务。主流的降级策略有基于RT (响应时间) 、异常比率和异常数的降级。 就比如贴吧类型的网站，当服务器吃不消的时候，可以选择把发帖功能关闭，注册功能关闭，改密码，改头像这些都关了，为了确保登录和浏览帖子这种核心的功能。 降级的手段大致有这么三种 强一致变为最后一致,延迟服务 干掉一些次要功能 简化流程 每个服务都需要制定自己的降级策略，根据服务不同的优先级来设定降级方案。另外降级策略最好是由开关系统或者配置系统统一控制。一般而言都会建立一个独立的降级系统，可以灵活且批量的配置服务器的降级功能。当然也有用代码自动降级的，例如接口超时降级、失败重试多次降级等。具体失败几次，超时设置多久，由你们的业务等其他因素决定。开个小会，定个值，扔线上去看看情况。根据情况再调优。 熔断和限流都可以认为是降级的一种方式 https://xie.infoq.cn/article/2593d1a3b9e1e06cac6502c4f?utm_source=rss&utm_medium=article