eric1984的专栏

3》重置当前分支的提交历史，使它和dev分支的提交历史保持一致，即：原本只出现在dev分支上的提交记录c1，现在也出现在了当前分支上；1》找到当前分支和dev分支各自的最新提交c1和c2；然后从c1和c2开始向前回溯，找到它们在提交历史上的“共同祖先”c0；4》在这个基础上，然后再逐一追加只在当前分支上出现的提交记录，比如：c2，整个过程才算结束。2》把当前分支上从c0往后的每个提交记录和c0进行对比，并把对比结果存到临时文件里；一、把别的分支的commit顺序迁移到当前分支（重建基线），线性化提交历史。

/ DCI，app层与domain层之间有了一个role的桥廊，app（context）不会耦合特别多的属性，只耦合少部分的行为。对聚合根的直接耦合，变成了对角色的使用。DDD里聚合根同时实现类的属性和方法，容易出现上帝类；传统的ddd架构，领域层是纯oop模型，应用层使用领域层的聚合根来完成业务，DCI是把。总结：app与domain层中间，添加一层role，用来切分聚合根。// context里面仅依赖角色，不直接依赖聚合根Person。// 纯DDD，聚合根是铁板一块，容易形成上帝类。

5、显示效果：默认js不做任何自适应的时候（位置和大小都是固定像素值），os放大控件大小时，os的控件都放大了，chrome全屏时自己做了自适应，保证不会超出屏幕。html的渲染区域变大了，html里面的字体放大了，相对位置变大了，但是屏幕分辨率不变，所以导致部分内容会超出屏幕范围，需要左右拖拽来显示。3、操作系统的控件大小伸缩：操作系统会在默认屏幕分辨率的基础上，做大小的伸缩，操作系统提供的控件会做伸缩的自适应：分辨率变大时，字体和控件会等比例放大。2、显示器分辨率 硬件的分辨率，不一定和大小正相关。

多对多的关系数据结构上用2个聚合实现，领域函数上使用实体。// 领域服务是添加作者，数据结构是存储关联关系。DDD里的核心关系，1、聚合 2、关联。

GC最佳实践

1、数据仓库：传统的数仓ETL建模和分析处理2、数据湖：基于原始的半结构化、非结构化数据，使用分布式的计算任务进行分析和处理，不是基于良好建模的数仓，强调数据的动态模型、原始的数据3、湖仓一体：数据就是一份，底层是企业的全部数据，包括结构化、半结构化、非结构化，中间通过统一的加工处理直接支撑上层所有仓的应用(BI、报表以及湖的应用)，不再需要ETL连通（原来是存储2份数据，1份是原始的，1份是ETL之后的），数据能够直接用来进行分析。4、胡仓一体技术实现方案：1》Snowflake（分布式并行计算

1、整体是自定义了一门dsl，并实现了指令集和执行器2、核心数据结构QueryModel 语法树 QIL 指令集 Query：整体dsl解析执行的门面 DataModel：通用数据类型，可以解包成具体的object list 原子类型等UDF （User-Defined Function）用户定义函数，mysql的udf是用c写的，dataql的udf是用java写的（注册后可以在脚本中使用）3、运行时核心逻辑QueryResultImpl QueryImpl.execute(Custom...

mysql的锁锁的颗粒度，决定并发度和速度InnoDB的行锁是针对索引加的锁，不是针对记录加的锁。并且该索引不能失效，否则都会从行锁升级为表锁；rr的业务场景：多个相关的查询，同时取出来使用，并且要保证业务含义一致1》 对数。 上个月的余额，本月的账单（3个结果），当前的余额（修改了1个结果），正常应该是上月余额-本月账单==当前余额，现在因为2次读时，差了1个更新事务，所以对不上了2》 汇总数额不对。同一个事务内，先查详情，后聚合count，详情加起来和count返回的结果不一致3》..

多进程模型：master负责管理，worker负责处理连接和http请求sendfile：从默认的 磁盘--内核（read文件）--用户态--内核（write数据）--协议栈，变成磁盘--内核--协议栈upstream 定义后端的多个服务器地址server { listen 80 default_server; # 域名不匹配时的默认server listen [::]:80 default_server; server...

1、全局变量 环境变量 测试集变量{{variable}}2、测试脚本pm.test("Status code is 200", function () { pm.response.to.have.status(200); });3、发送前的脚本pm.globals.set("filter", "user-1");4、工作流 用test脚本来实现postman.setNextRequest('Postman Echo PUT')5、取出数据塞入全局变量var jsonData = pm

RR隔离级别下，整个事务开始时创建1个read view，后面的事务提交的结果，不会体现在读的结果里。RC隔离级别下，每个快照读，都会生成新的read view。mysql的所有的快照读，都不保证读到最新的结果，因为都不会加锁...

调，是应用为了实现某种逻辑而写的，一般基于互斥实现4、POSIX中定义的工具：内存barrier（避免多核cache导致的不一致）、mutex、condition、readwritelock、semaphore5、管程 monitor，把pv操作、加解锁抽象成数据结构，而不是散列在线程的代码里6、io缓存：cpu用DMA缓存到内核，之后拷贝到用户空间，比不用缓存好的地方：不用多次分配和释放内存；可以一次让磁盘读入整个块；在读入的时候，使用更少的cpu干预。7、内存映射：内核和用户空间使用同一

uild  cmake ..               cmake --build . 编译结果在每个子目录中

据分析2、ETL、数据仓库->大数据、大规模分布式数据处理->大规模机器学习->实时数据处理三、各个技术之间的演化对应关系mysql VS redis ETL VS storm数据仓库 VS hive数据挖掘 VS 机器学习OA VS 工作流IPC VS RPC内存 VS redis查找 VS 搜索（solr）文件系统 VS 分布式存储map/reduce VS 流计算

时性的任务可以使用调度器scheduler（每个任务一个线程，对于周期性任务非常浪费资源）2、如果有非常多调度性任务需要处理，可以每台机器分别布置一套调度器，并且不同机器调度不同的任务。3、2中每个机器进行调度很浪费（比如每1ms检查一次条件），不同的任务不能跨机器共享硬件，而且无法看到所有调度任务的整体的情况。另一种方案是，一个master进行时间和条件的调度，到了执行条件再扔给具体的机器执行，这样很方便进行横向扩展，只要维护一套调度集群，就解决所有调度需求（分布式调度）4、分布式调度引进

oader加载具体的实现（通过无参数构造函数实现对象创建）2、提供者在jar包的META-INF/services/目录里创建前面接口的全名文件3、在文本文件里写上具体实现类的全名4、具体的例子，数据库驱动spi META-INF/services/java.sql.Driver ，实现者 /mysql-connector-java/5.1.29/mysql-connector-java-5.1.29.jar

个term对应原来的一个field），并且term本身进行索引（trie 树）3、数据进行压缩4、组合查询时的优化注意点：ID尽量有规律、去掉不必要的索引、去掉不必要的analyzed

、es的改进    1、新的segment不是fsync到磁盘，而是同步到内核文件缓存（默认1s），内核文件缓存再在合适的时间真正刷磁盘    2、fsync之前怎么保证可靠？使用translog记录这段时间的操作，translog本身每5秒刷一次磁盘    3、合并小的旧的segment  代码： Settings settings = ImmutableSettings.settingsBuilder()              .put("clien

;dubbo:reference id="userService" interface="org.huxin.dubbo.test.user.service.UserInterface"                     stub="org.huxin.dubbo.test.UserServiceStub" protocol="dubbo"/>         public class UserS

据集合，用于支持管理决策(Decision Making Support)。    其中最核心的是集成。    2、ETL：抽取 转换 加载 把数据从不同的oltp系统中集成到数据仓库中的过程    3、数据模型：仓库里的数据怎么组织？（数据结构）目前业界的事实标准是 维度模型    4、大数据：大数据指不用随机分析法（抽样调查）这样捷径，而采用所有数据进行分析处理。大数据的5V特点（IBM提出）：Volume（大量）、Velocity（高速）、Variety（多样）、Value（低价值密度