守株阁

  虚拟机意味着单独的指令集体系结构（ISA Instruction Set Architecture）。

#为什么要自建一个离线平台# 可以优化资源利用率。 业务平台应该把精力放在业务上。 #什么是实时计算# 强调响应时间短（相对于离线计算）：毫秒级、亚秒级、秒级。T+1 的报表都是离线计算。 数据的价值随着时间的流逝而迅速降低。 常见技术方案： 流计算 + 实时存储 or 消息队列 流计算 + 实现 OLAP #什么是流式计算# 实时且无界。 数据驱动计算，事件触发。 有状态及持续集成。 流计算引擎：Spark Streaming、Flink Streaming、Storm/JStorm、Samza 等。 #Spark Streaming 模型# Micro-Batch 模式。看起来是流式处理的，实际上还是一小批一小批处理的。从批处理走到流处理。 最小延时：batch 的处理时间 最大延时：batch interval（通常2s-10s） + batch 处理时间。 使用场景：数据清洗（实时数据通道）、数据 ETL 等。 对于熟悉 Spark 批处理的 RD 非常容易上手。 #Flink Streaming# Native Streaming。 低延时，通常在毫秒...

Goroutine 是绿色线程，下面自带调度器。可以在 syscall 进入阻塞状态的时候自动出让 CPU（类似 Java 在进入锁以前自动引入自旋，这实际上是一种抢占式调度–preemptive scheduling），也可以通过runtime.Gosched()主动出让 CPU，调度器还可能无缘由地主动抢占 Goroutine 的时间片（比如已经运行了10ms）。因为是绿色线程，所以可以很便宜地创造百万Goroutine。在 Go 1.5 以后，可以通过 GOMAXPROCS 来使用更多的逻辑 CPU（而不也是系统进程）来利用多核。主线程不是主线程，主线程也是一个 main goroutine。 Go 关键字基本就等同于 Java 中提交一个 Runnable 到 CompletableFuture 的 CommonPool。在没有 Channel 的帮助时，goroutine 几乎可以等同于一个绿色的守护线程。 Go 也是有 mutex 的，但是不提倡使用，用 channel 最好。 share memory by communicating。 channel 是通过描述...

  比较好用的两个 vim 寄存器代码： 1234567#删除全部内容:%d# 在 vim 下，拷贝全部的代码:%y+# 在 mac 的 vim 下，拷贝全部的代码:%w !pbcopy

保险电销的发迹史 电销在早期国内的常见渠道方式 零售-求职-电视购物-保险-房地产-理财-催收-教育 人才从一个行业去到另一个行业。保险电销卖的保险业都在慢慢变化。 保险电销的发展历程 电销鼻祖–中美大都会人寿04年。先收集用户信息，然后再卖保险。 真正符合国际发展主流的电销–招商信诺。佣金模式很重要。 国内的保险电销为何逐步衰落。保险电销两三年后，坐席两三万很容易。职业瓶颈也出现了。 保险电销核心竞争力。 保险电销的流程 开场（黄金三十秒） 产品介绍 激发需求 核保 促成 成交确认 保险销售的套路 为客户创造需求。 如何激发你的保险需求。 如何未曾谋面判断你的财务状况。 如何让你冲动消费。 保险电销目前的机遇 结合互联网提升效率（互联网+电销） 健康险需求已经被激发，互联网模式有待考究，需要电销介入。 车险电销需要改变（系统智能化）。 由人海战术转变精英战术。 保险的逻辑 风险转移-保险可以解决风险的不确定性。愿意用确定的金额来为不确定性的风险买单。 保险的机制是独特的经济补偿机制。 有杠杆。 法律保护保险金。 保险资金投融资作用。 保险促进产业链整合。 ...

#系统调用的过程#   系统有些高特权的操作，比如访问 IO 设备，修改内核状态，修改其他程序，在rings模型下，只有rings 0才能做得到。用户程序(通常是ring3)在自己的地址空间里面，是没有办法看到这些资源，也就无法修改它们。这时候用户程序就需要request service，发出软（件）中断，让程序trapped 进内核态(通过int 0x80 指令，实际上这不仅仅是进程的状态转换，也是进程的状态转换)。实际上此时的控制权已经交给内核了，内核可以在自己的内核地址空间里面，使用高特权操作，特权操作做完了以后，控制权才交回给用户程序。这个过程就成为syscall。x86 虽然有四层 ring，但通常只使用了0和3层ring。   系统通常提供API或者lib来提供syscall的能力。比如在 Unix-Like系统里，就是glibc。lib提供的函数，通常被称为Wrapper Function。 #系统调用的代价在哪里#   每次产生系统调用，程序的上下文通常会产生切换，CPU必然是要把进程状态寄存器里面往内存里塞，再把其他进程的上下文从内存里往寄存器里面塞。即使只是...

  GIL （Global Interpreter Lock）的存在虽然无法利用多核，但是可以勉强让系统在在单核上，任何一个线程使用过多时间片/主动放弃 CPU 的时候，让其他线程上下文切入进来。算是尽量跑满CPU吧。Python中的对象很多都是默认线程安全的，GIL的这种不可见的特性，让很多旧的程序依赖起 GIL，以至于无法从Python中移除掉它。GIL 的存在，让 Python 特别适合跑 Nodejs 爬虫一样的 IO 密集型（IO-bound）任务，反而不适合跑CPU 密集型任务（CPU-bound）。但实际上这种混蛋多线程的形式，恐怕还不如 EventLoop 的 Nodejs，因为多了很多 Context Switch 的代价。

面向对象，聚讼纷纷。

先上结论：幽灵类型（Phantom Type）顾名思义，就是幽灵般的类型，这种类型往往在运行时可以消失，因为在运行时没有任何作用，它们最大的特点就是没有任何实例（Java 的 Void 就是幽灵类型的例子）。是一种可以把有些运行时才能检测到的错误，在编译时检测出来的技巧。按照有些老外的观点，就是“Making Wrong Code Look Wrong”。在面向对象的编程语言之中，幽灵类型的实现，往往与状态模式较为接近，但比状态模式提供了更强的纠错功能。在Java 5 以后的版本里，程序员可以使用泛型。通过泛型的类型参数，Java 中也拥有了幽灵类型的能力。 上面的阐述是不是很难看懂？我也觉得拗口，让我们直接进入具体的例子。假设我们要写一个飞机控制程序，操作飞机起飞或者落地。这个程序有一个非常强的业务约束，就是必须保证飞机一开始必须出现在的地上，只有在地上的飞机可以起飞，只有起飞的飞机可以落地，那么我们应该怎样设计我们的程序（主要是类型关系），来保证这个约束必然成立呢？ 让我们先来定义一组状态接口: 123456789101112131415161718192021/** * F...

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174/* * 改编自 IBM 的源码示例。 */package mainimport ( "bytes" "fmt" ...