守株阁

职场求生攻略.xmind

Redis 的 memory infoRedis 的内存使用状况可以使用info memory来获取。 需要重点关注的值是 used_memory_rss（用于存储消耗的物理内存），used_memory（用于存储消耗的内存= 物理内存 + 硬盘），以及他们的比值mem_fragmentation_ratio（used_memory_rss/used_memory）。 used_memory_rss或者used_memory很高时，意味着当前的 Redis 实例正在蚕食系统中的内存/硬盘资源。 当这个mem_fragmentation_ratio大于 1 的时候，意味着用于存储消耗的物理内存超过了 Redis 自己掌控的内存值，也就意味着当前有些未能回收的内存泄漏或者碎片。 当这个mem_fragmentation_ratio小于 1 的时候，这意味着有一部分用于存储的内存，实际上是在使用虚拟内存中的 swap 空间，此时 Redis 的性能会非常差。 Redis 的内存轮廓memory_used = 进程自身消耗的内存 + 存储对象的内存（大头） + buffer...

Java中的条件编译

“数量上的优势不论在战术上还是战略上都是最普遍的致胜因素。 战略上最重要而又最简单的准则是集中兵力。 人们必须承认，数量上的优势是决定一次战斗结果的最重要的因素，只不过这种优势必须足以抵消其他同时起作用的条件。从这里得出一个直接的结论:必须在决定性的地点把尽可能多的军队投入战斗。 在一般条件下进行的大小战斗中，不论其他方面的条件如何不利，只要有显著的数量上的优势，而且无需超过一倍，就足以取得胜利了。 如果我们不抱偏见地研究现代战史，那就必须承认，数量上的优势越来越起着决定性的作用。因此，在决定性的战斗中尽可能多地集中兵力这个原则，在现在必须提到过去更高的地位。 数量上的优势应该看作是基本原则，不论在什么地方都是应该首先和尽量争取的。 一切用于某一战略目的的现有兵力应该同时使用，而且越是把一切兵力集中用于一切行动和一个时刻就越好。” 《孙子-谋攻篇》：故用兵之法，十则围之，五则攻之，倍则分之，敌则能战之，少则能逃之，不若则能避之。

结算账务基础知识.xmind 本文来自于： 《中国央行支付清算系统概述（上）》 《清分、结算、清算、对账》 《银联清算业务基础知识介绍...

会计科目会计科目.xmind 财务报表三大财务报表.xmind

刻戒于碑，铸法于鼎 软件特性、质量属性。 将两个元素以某种方式连接在一起，就形成了结构。 module component-connector 就是我们经常讲的系统交叉点 allocation 就涉及到我们的部署设计 每一本书都会讲到利益相关者，也就是...

解决问题的过程，是探索的过程。 19 世纪 30 年代，英国工程师巴贝奇发明了差分机，用来计算数学用表。巴贝奇还构思了分析机，意图使用一般性方法，用来解决通用计算问题。巴贝奇自己还是英国科学学会会员，以及一位经济学家。巴贝奇使用齿轮和条杆来制造分析机，受到时代所限，始终无法落地，没有得到英国政府资助，没有继续下去。后来有长达一百年的时间里，人们转而使用模拟的方式解决问题。 图灵对计算机的贡献是制造了通用机。 冯诺依曼的贡献是制造了“一般性方法”，即编程。 实时计算的发展历程是：美军飞行员的训练需求诞生了旋风计算机，而后又产生了 SAGE 系统。这两个项目为美国的商用计算机行业，培养了大量程序员。而且使 IBM 认识到商用计算机的商业潜力，斥巨资开发了 SABRE 系统。 IBM 是靠生产办公机器起家的。 computer 最早是指计算员。计算机的发展序列为：哈佛马克一号，ENIAC 和 EDVAC、EDSAC（威尔克斯）、UNIVAC。个人计算机首先是阿塔利的“牵牛星 8800”，然后是苹果，苹果 2，丽萨（太贵而卖不出去），麦金塔（平价版...

自序领导者总是嘴上以人为本，但对待员工却弃之如敝履。 人的一生用在工作的时间是最多的。工作的经历-甚至为最好的一些雇主工作-令人动力尽失、丢掉本性，这样是不对的。 杰克韦尔奇和人力资源主管比尔康纳迪共同建立了广受赞誉的员工管理体系，严格按照绩效表现对员工进行排名，每 12 个月至 18 个月重新调配拔尖人才的工作岗位，同时还在纽约的克罗顿维尔建立了全球培训中心。 20-70-10 的绩效排名体系。最开头的人才会得到赞扬，最末位的人才要遭到解雇。 韦尔奇最著名的是他的六西格玛（six-sigma）。 谷歌的企业文化不提倡穿西装工作。 前言 为什么谷歌的原则也对你适用“10 亿小时之前，现代智人出现。 10 亿分钟之前，基督教诞生。 10 亿秒之前，IBM 个人电脑发布。 10...

本文是如何写《复杂业务系统》和《我眼中的阿里经济体的中台架构演进》的续篇。 本文探讨到底不确定性和复杂性源于何处，并引出互联网业务系统的一种“可适应性架构”，适用于平台型业务系统。 定义问题软件难写，是软件工程师的共同感觉。 特别地，对于中国的互联网公司的“业务团队”的工程师而言，“业务系统”在业务的复杂度堆积到一定程度以后，软件本身的“熵增效应”会特别严重：一个业务系统的内部会充满了难以理解的分层、堆积如山的 if-else...