Neo's Blog

自增ID

1、一张表，里面有 ID 自增主键，当 insert 了 17 条记录之后，删除了第 15,16,17 条记录，再把 Mysql 重启，再 insert 一条记录，这条记录的 ID 是 18 还是 15 ？

(1) 如果表的类型是 MyISAM，那么是 18

因为 MyISAM 表会把自增主键的最大 ID 记录到数据文件里，重启 MySQL 自增主键的最大ID 也不会丢失

（2）如果表的类型是 InnoDB，那么是 15

InnoDB 表只是把自增主键的最大 ID 记录到内存中，所以重启数据库或者是对表进OPTIMIZE 操作，都会导致最大 ID 丢失

字符串索引

还有没有其他方式帮助字符串建立索引

比如能够给确定业务需求里面只有按照身份证等值查询的需求，需要给身份证加索引，有没有什么办法，占用更小空间，也能达到相同的查询效率。

第一种方式是使用倒序存储

【基础假设】存储的字符串后半部分的区分度相对更高

身份证最后 6 位，没有重复逻辑，因此最后 6 位可能提供了足够的区分度。

先倒序存储，然后再创建前缀索引。

如果存储身份证的时候倒过来存，每次查询的时候,可以这样：

select field list from t where id card reverse(‘input id card string);
第二种方式使用 hash 字段

可以使用表上再创建一个整数字段，来保持身份证的校验码，同时在这个字段创建索引。

alter table t add id card crc int unsigned, add index（id_card_crc);
每次插入新记录的时候，都同时使用 crc32 这个函数 得到校验码填到这个新字段，校验码可能存在冲突，也就是两个不同的身份证通过 crc32() 函数得到的结果可能是相同的，查询要查询语句 where 部分判断 id_card 的值是精确相同的。

排序

全字段排序 VS row_id排序

MySQL 的一个设计思想：如果内存够，就要多利用内存，尽量减少磁盘访问。 对于 InnoDB 表来说，rowid 排序会要求回表多造成磁盘读，因此不会被优先选择。

如果数据量很大，内存中无法存下这么多，就会使用磁盘临时文件来辅助排序，称为外部排序；
外部排序，MySQL会分为好几份单独的临时文件来存放排序后的数据，一般是磁盘文件中进行归并，然后将这些文件合并成一个大文件；

参考：
https://blog.csdn.net/qq_29066329/article/details/90036836

我们通过几个问题来介绍InnoDB存储引擎

LBCC VS MVCC

Lock Based Concurrency Control（LBCC）

保证前后两次读取数据一致，那么我读取数据的时候，锁定我要操作的数据，不允许其他的事务修改就行了。如果仅仅是基于锁来实现事务隔离，一个事务读取的时候不允许其他时候修改，那就意味着不支持并发的读写操作，而我们的大多数应用都是读多写少的，这样会极大地影响操作数据的效率。

MVCC Multi Version Concurrency Control（MVCC)

MVCC是InnoDB存储引擎为了实现事务的隔离级别而引入的一种乐观锁机制。
如果要让一个事务前后两次读取的数据保持一致，那么我们可以在修改数据的时候给它建立一个备份或者叫快照，后面再来读取这个快照就行了。

MVCC的目的在于：我可以查到在我这个事务开始之前已经存在的数据，即使它在后面被修改或者删除了。在我这个事务之后新增的数据，我是查不到的。

Undo Log

Undo log: 是什么？ 通过它解决了什么问题？ 数据的多个版本，临时写在undo log中，并通过链表管理起来。

InnoDB为数据库中的每一行添加了三个隐藏字段：DB_TRX_ID(事务版本号)、DB_ROLL_PTR(回滚指针)、DB_ROW_ID(隐藏ID)。

• DB_TRX_ID：记录了创建/更新这条数据的事务版本号（版本号会递增）。
• DB_ROLL_PTR：记录了一个指向undo log中历史版本的数据指针。（用来支持回滚操作）
• DB_ROW_ID：一个自增的隐藏行ID。

InnoDB基于事务版本号、回滚指针这两个字段，可以在undo log中形成一个单向链表，最新版本的数据放在链表头部，历史数据通过DB_ROLL_PTR指针进行关联。如下图所示

MVCC

一致性读视图包括：视图数组（活跃的事务） + 高水位（已经创建过的事务ID + 1）

InnoDB在事务开启后执行第一个查询时，会创建一个快照（下文称之为ReadView），这个ReadView包含了以下信息

• m_ids: 活动事务id列表（活动事务指的是已经开始、尚未提交/回滚的事务）
• min_trx_id: 最小活动事务id
• max_trx_id: 最大活动事务id
• creator_trx_id:当前事务id

紧接着InnoDB会通过查询语句定位到最新版本的数据行，并根据以下规则获取到可以访问的数据版本。

• 如果被访问版本的trx_id，与readview中的creator_trx_id值相同，表明当前事务在访问自己修改过的记录，直接返回该版本的数据；
• 如果被访问版本的trx_id，小于readview中的min_trx_id值，表明生成该版本的事务在当前事务生成readview前已经提交，直接返回该版本的数据；
• 如果被访问版本的trx_id，大于或等于readview中的max_trx_id值，表明生成该版本的事务在当前事务生成readview后才开启，此时该版本不可以被当前事务访问，需要通过隐藏的回滚指针从undo log中读取历史版本；
• 如果被访问版本的trx_id，在readview的min_trx_id和max_trx_id之间，则需要判断trx_id值是否在m_ids列表中？
  (1)如果在：说明readview创建时，创建该版本数据的事务还未提交，因此需要通过回滚指针读取历史版本并返回。
  (2)如果不在：说明readview创建时，创建该版本数据的事务已经提交，所以直接返回该版本的数据；

InnoDB如何解决各种隔离问题

第一、InnoDB是如何解决脏读问题的？

如果是读已提交，那么事务每一个语句执行前都会重新计算出新的视图，也就解决了脏读问题。

第二、InnoDB是如何解决不可重复读问题的？

如果是可重复读，那么事务开启时创建一次访问视图。同一个事务中后续所有的查询共用一个ReadView，由此便解决了不可重复读的问题。

第三、InnoDB是如何解决幻读问题的？

快照读、锁定读：了解这两种读取方式的发生时机以及如何实现的？

快照读是指通过MVCC实现的非阻塞读，常见的快照读操作如下：

select xxx from xxx

当前读也叫加锁读，每次读取数据都是读取数据的最新版本，并且会对其进行加锁。常见的当前读操作如下

• select xxx from xxx lock in share mode (共享锁/读锁)
• select xxx from xxx for update （排它锁/写锁）
• update 、delete、insert

为什么要区分这两种读操作呢？因为MVCC并不能解决幻读的问题。即使是在可重复读级别，通过当前读依然会出现幻读问题。

此问题最终是通过间隙锁（next-key lock)来解决的。

InnoDB是如何解决事务的持久性问题

redo log buffer (内存中)是由首尾相连的四个文件组成的，它们分别是：ib_logfile_1、ib_logfile_2、ib_logfile_3、ib_logfile_4。

• write pos 是当前记录的位置，一边写一边后移，写到第 3 号文件末尾后就回到 0 号文件开头。
• checkpoint 是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。
• write pos 和 checkpoint 之间的是“粉板”上还空着的部分，可以用来记录新的操作。
• 如果 write pos 追上 checkpoint，表示“粉板”满了，这时候不能再执行新的更新，得停下来先擦掉一些记录，把 checkpoint 推进一下。
• 有了 redo log，当数据库发生宕机重启后，可通过 redo log将未落盘的数据（check point之后的数据）恢复，保证已经提交的事务记录不会丢失，这种能力称为crash-safe。

Redo log是什么？ 通过它解决了什么问题？

redo log是InnoDB存储引擎为了解决事务持久性而引入的WAL技术。借助redo log，InnoDB存储引擎将事务的commit提交简化为一次内存操作与一次磁盘写入操作。如果磁盘页中的数据发生了丢失，也就是在崩溃恢复过程中，存储引擎会通过重做redo log中的操作来进行数据恢复。

binlog又是什么？他是干什么用的？ 了解主从同步原理。

binlog是Mysql server层为了解决主从数据同步而引入的一套日志系统。binlog中记录的是一个数据行发生了什么操作。

Redo Log与binlog的两阶段提交

• prepare阶段，先写入rede log（状态为准备中）
• 写入binlog（状态为已提交）—- TX_ID
• commit阶段，写入redo log（状态为已提交）

而两阶段提交就是让这两个状态保持逻辑上的一致。redolog 用于恢复主机故障时的未更新的物理数据，binlog 用于备份操作。两者本身就是两个独立的个体，要想保持一致，就必须使用分布式事务的解决方案来处理。

为什么需要两阶段提交呢?

如果不用两阶段提交的话，可能会出现这样情况
先写 redo log，crash 后 bin log 备份恢复时少了一次更新，与当前数据不一致。
先写 bin log，crash 后，由于 redo log 没写入，事务无效，所以后续 bin log 备份恢复时，数据不一致。
两阶段提交就是为了保证 redo log 和 binlog 数据的安全一致性。只有在这两个日志文件逻辑上高度一致了才能放心的使用。
在恢复数据时，redolog 状态为 commit 则说明 binlog 也成功，直接恢复数据；如果 redolog 是 prepare，则需要查询对应的 binlog事务是否成功，决定是回滚还是执行。

InnoDB的几个关键特性

insert buffer、double write、自适应hash索引、异步写等

参考：
https://blog.csdn.net/hahazz233/article/details/125372412

数据库中涉及到锁的一些经常考察的知识点

悲观锁 VS 乐观锁

首先悲观锁（Pessimistic Lock）、乐观锁并不是两种锁，而是两种思想，两种用于实现并发控制的思想。

其中，悲观锁指的是对数据被外界修改持悲观态度，认为数据大概率会被他人修改，所以在我准备修改数据时，我会对该数据加锁以避免其他人对该数据进行并发访问。

而乐观锁指的是对外部修改数据持乐观态度，认为数据不会修改，所以我会直接对数据进行修改，在修改的以后再进行冲突的检查。如果修改失败了，我再决定如何去做。

悲观锁适合写多读少的场景，而乐观锁适合读多写少的场景。

悲观锁一般通过数据库锁来实现，而乐观锁一般是通过CAS来实现。

意向锁

意向锁是什么？ 为什么需要意向锁？

意向锁是实现多粒度锁的一种方式，是表锁，分为意向排他锁、意向共享锁；

意向锁之间是兼容的；意向锁与表级别的共享锁、拍他锁是可能互斥的；

意向锁与行级的互斥锁、共享锁是兼容的；

实现意向锁的目的有两个：第一，让多粒度锁共存；第二，加快是否可以加锁的判定效率。

考虑一种场景，事务A尝试修改一条数据，此时事务B需要加表锁。 如果没有意向锁，数据库系统需要怎么做？ - 系统需要扫描对所有的行加锁。

意向锁也不会和数据行共享锁S、排它锁X发生冲突。

那这玩意干啥的？

update new_table set user_id = 911 where id = 1;
假设我们执行这么一条语句，innodb除了在id=1的这条记录上增加了行级X锁之前，还对所在表添加了一个意向排它锁。

这个时候如果我们有针对 new_table 的表级锁操作，如：alter table、drop table、lock table 的操作时，会先检查对应表是否存在意向排它锁，若存在则等待锁释放。

next-key lock

Record lock、gap lock、next-key lock

• record lock, 行锁， 锁直接加在索引记录上面，锁住的是key。
• gap lock, 间隙锁，用来解决幻读问题
• next-key lock， gap lock + reocrd lock

关于next-key lock的两个原则、两个优化、一个bug:

• 原则1: 加锁的基本单位是next-key lock, 前开后闭区间，（A, B]
• 原则2: 查找过程中遇到的对象才会加锁(延迟加锁)
• 优化1: 索引上的等值查询，给唯一索引加锁的时候，next-key lock退化为行锁
• 优化2: 索引上的等值查询，向右遍历时且最后一个值不满足等值条件时，next-key lock退化为gap lock
• bug: 唯一索引的范围查找会访问到不满足条件的第一个值为止。

参考：https://blog.csdn.net/zwx900102/article/details/106544634?utm_medium=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.control&dist_request_id=&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.control

———-User——-

application write(fd,buf.len)

———-Kernel——-

File Validate file descriptor.
Sockets Copy/append buf to socket buffer.
TCP Create TCP segment according to TCP state, Compute checksum.
IP Add IP header,perform IP routing. Compute checksum.
Ethernet Add Ethernet header,perform ARP.
Driver Tell NIC to send the packet.

———-Device——-
NIC Fetch the packet from host memory and send it. Interrupt the host when send is done.

缓冲区被塞满

如图所示，物理介质上的数据帧到达后首先由NIC（网络适配器）读取，写入设备内部缓冲区Ring Buffer中，再由中断处理程序触发Softirq从中消费，Ring Buffer的大小因网卡设备而异。当网络数据包到达（生产）的速率快于内核处理（消费）的速率时，Ring Buffer很快会被填满，新来的数据包将被丢弃；

报文mac地址丢包

一般计算机网卡都工作在非混杂模式下，此时网卡只接受来自网络端口的目的地址指向自己的数据，如果报文的目的mac地址不是对端的接口的mac地址，一般都会丢包，一般这种情况很有可能是源端设置静态arp表项或者动态学习的arp表项没有及时更新，但目的端mac地址已发生变化（换了网卡），没有更新通知到源端（比如更新报文被丢失，中间交换机异常等情况）；

长链接 VS 短链接

长连接：

长连接多用于操作频繁，点对点的通讯（尤其是需要下行消息的场景，例如即时通信），而且连接数不能太多的情况。

短连接：

web网站的http服务一般都用短连接。因为长连接对于服务器来说要耗费一定的资源。

像web网站这么频繁的成千上万甚至上亿客户端的连接用短连接更省一些资源。试想如果都用长连接，而且同时用成千上万的用户，每个用户都占有一个连接的话，可想而知服务器的压力有多大。所以并发量大，但是每个用户又不需频繁操作的情况下需要短连接。

TCP与UDP的区别

流模式 VS 数据报模式、连接 VS 无连接、可靠性

TCP与UDP应用

TCP:对效率要求低，对准确性要求较高 (如文件传输、重要状态的更新等)

eg. STMP, TELNET, HTTP, FTP

UDP:对效率要求高，对准确性要求较低 (如视频传输、实时通信等)。

eg. DNS,TFTP,RIP,DHCP,SNMP

TCP状态迁移图

FIN 段是可以携带数据的，比如客户端可以在它发送的最后一块数据块中“捎带” FIN 段。当然也可以单独发送FIN。不管 FIN 段是否携带数据，都需要消耗一个序列号。

TCP三次握手的缺陷：Sync Flood攻击

确认机制与超时重传

TCP通过确认机制 ( acknowledge ) 保证了信息的成功发送。

发送的数据编号被称为序列号(Sequence Number - SN)

确认的数据编号被称为确认序列号(Ackonwledge Sequence Number - ASN)

TCP协议正是通过序列号保证了传输顺序

ASN = 填写要接收的下一个字节的数据(本次收到的数据的最后一个字节的下一个)

TCP是有发送缓冲区的，用于暂时保存已发送，未应答的数据，为什么要进行保存，因为TCP为了保证数据确切地被对方接收到，需要对方发送的ASN，如果对方没有应答，就需要重发，如果不对数据进行保存，就没有办法重发了，所以发送缓冲区主要也是为了保证可靠性而存在的

TCP有接收缓冲区，这与UDP协议一致，因为接收到的信息，不一定马上就能被应用层取走使用

TCP规定，SYN报文段不能携带数据，但要消耗一个序号；ACK报文段可以携带数据，但如果不携带数据则不消耗序号

客户端在收到第三次挥手的FIN 报文之后，再次收到服务端的数据包会怎么处理

客户端如果收到乱序的 FIN 报文，会将FIN包加入到「乱序队列」，并不会进入到 TIME_WAIT 状态。等收到前面被网络延迟的数据包时，重组报文得到完整顺序的数据包之后，发现有 FIN 标志，这时才会进入 TIME_WAIT 状态。

关于TIME_WAIT存在的必要性

MSL 是 Maximum Segment Lifetime，报文最大生存时间，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。

1）为实现TCP全双工连接的可靠释放

由TCP状态变迁图可知，假设发起主动关闭的一方（client）最后发送的ACK在网络中丢失，由于TCP协议的重传机制，执行被动关闭的一方（server）将会重发其FIN，在该FIN到达client之前，client必须维护这条连接状态，也就说这条TCP连接所对应的资源（client方的local_ip,local_port）不能被立即释放或重新分配，直到另一方重发的FIN达到之后，client重发ACK后，经过2MSL时间周期没有再收到另一方的FIN之后，该TCP连接才能恢复初始的CLOSED状态。如果主动关闭一方不维护这样一个TIME_WAIT状态，那么当被动关闭一方重发的FIN到达时，主动关闭一方的TCP传输层会用RST包响应对方，这会被对方认为是有错误发生，然而这事实上只是正常的关闭连接过程，并非异常。

2）为使旧的数据包在网络因过期而消失；防止lost duplicate对后续新建正常链接的传输造成破坏。

lost duplicate在实际的网络中非常常见，经常是由于路由器产生故障，路径无法收敛，导致一个packet在路由器A，B，C之间做类似死循环的跳转。IP头部有个TTL，限制了一个包在网络中的最大跳数，因此这个包有两种命运，要么最后TTL变为0，在网络中消失；要么TTL在变为0之前路由器路径收敛，它凭借剩余的TTL跳数终于到达目的地。但非常可惜的是TCP通过超时重传机制在早些时候发送了一个跟它一模一样的包，并先于它达到了目的地，因此它的命运也就注定被TCP协议栈抛弃。

另外一个概念叫做incarnation connection，指跟上次的socket pair一摸一样的新连接，叫做incarnation of previous connection。

lost duplicate加上incarnation connection，则会对我们的传输造成致命的错误。

大家都知道TCP是流式的，所有包到达的顺序是不一致的，依靠序列号由TCP协议栈做顺序的拼接；假设一个incarnation connection这时收到的seq=1000, 来了一个lost duplicate为seq=1000, len=1000, 则tcp认为这个lost duplicate合法，并存放入了receive buffer，导致传输出现错误。

通过一个2MSL TIME_WAIT状态，确保所有的lost duplicate都会消失掉，避免对新连接造成错误。

TCP拥塞控制

流量控制(狭义)：根据对方的接收能力来调节发送流量
拥塞控制：根据网络的承载能力来调节发送流量

接收窗口大致 = 接收缓冲区大小 - 已用大小(接收的数据，暂时没被应用层读走)

发送窗口 = min(接收窗口, 拥塞窗口)

核心：拥塞窗口 cwnd

第一阶段：慢开始、拥塞避免

快重传要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。

第二阶段；快重传、快恢复

快重传配合使用的还有快恢复算法，有以下两个要点:

①当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半。但是接下去并不执行慢开始算法。

②考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法。

CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。其目的是使用户可就近取得所需内容，解决Internet网络拥挤的状况，提高用户访问网站的响应速度。
关键技术

（1）内容发布：它借助于建立索引、缓存、流分裂、组播（Multicast）等技术，将内容发布或投递到距离用户最近的远程服务点（POP）处；

（2）内容路由：它是整体性的网络负载均衡技术，通过内容路由器中的重定向（DNS）机制，在多个远程POP上均衡用户的请求，以使用户请求得到最近内容源的响应；

（3）内容交换：它根据内容的可用性、服务器的可用性以及用户的背景，在POP的缓存服务器上，利用应用层交换、流分裂、重定向（ICP、WCCP）等技术，智能地平衡负载流量；

（4）性能管理：它通过内部和外部监控系统，获取网络部件的状况信息，测量内容发布的端到端性能（如包丢失、延时、平均带宽、启动时间、帧速率等），保证网络处于最佳的运行状态。

当你决定做某件事情之前，应该
（1）先确定目标（目标制定，要符合SMART原则）
（2）再明确原则（原则制定，不要模棱两可）
（3）最后去找实现目标的方法（方法制定，要切实可行）

先说目标

坦言之，要明确一件事情的目标，很难。其实很多事情，都会有至少两种解法，一种是长期的，收益会更大一些，但是需要的时间更长一些；一种是短期的，收益小一点，但是耗时短。这时候，我们的目标如何设定呢？其实特别考验一个人（领导者）的判断力，洞察力。

判断力的话，体现在一个人（领导者）需要能够预判业务将来的需要，从而决定这件事情的目标应该瞄准长期还是短期。

洞察力的话，体现在领导者能否看透这件事情的本质。我们的解法自然需要事情的本质相匹配。如果我们的目标解法跟事情的本质不匹配，耗时再短，这个目标也是不合理的（因为他的解法与本质不匹配，将来一定会出现冲突，一定需要推翻重来）

再说原则

关于原则有以下几点：
1）原则要符合公司、团队、个人的价值观
2）我们需要沉淀某些做事情的原则，避免重复纠结。

这些原则应该是我们团队达成的共识，是团队高效率协作的基础。

最后说方法

在符合原则的基础上，能够达成目标的方法有很多。关于这点，我的原则是：不设限，任其自由生长。

但是事后一定要复盘，要总结。无论方法成功还是失败，都要复盘、分析、总结、分享。

商业

自己定义：在交换的过程中，给消费者创造价值，同时自己获取利润的过程。

商业的几个关键要素：交易、交易成本、阻力（信息与新人不对称）

商业模式

商业模式，是利益相关者的交易结构。更优秀的商业结构，会有更低的交易成本。

商业模式，是一个企业满足消费者需求的系统，这个系统组织管理企业的各种资源（资金、原材料、人力资源、作业方式。销售方式信息、品牌和知识产权、企业所在的环境、创新力又称输入变量）形成能够消费者无法自力而必须购买的产品和服务（输出变量），因而具有自己能复制且别人无法复制或者自己在复制中占据市场优势地位的特性。

九宫图，可以清晰的罗列商业模式的关键点呢？分为四大类

客户方面：客户细分、客户关系、渠道通路

价值方面：价值定位

基础设施方面：关键活动、核心资源（你想对其他人有哪些优势）、重要伙伴

财务方面：描述运营这个模式引入的成本、收入来源

换成几个问题：

1. 真实的用户是谁？ 选择什么的细分市场标准？ 空间如何？
2. 怎么样触达用户？是直销还是经销？ 线上还是线下？
3. 提供什么样的核心服务？ 核心价值？痛点何在？如何定价？如何收费？
4. 资源支撑？核心资源是什么？ 需要什么样的伙伴或者上下游？
5. 财务状况？收入与成本？现金流状况？可持续性？

产业链，从原材料到最终用户的整个链条。

产业链，颗粒度选择；当宏观拆到微观：

1. 通过细粒度拆分才能明确到细分人群
2. 通过拆分才能够各环节的价值占比，有效防止风险（例如手机行业的芯片）
3. 通过拆分才能够反映出竞争的格局与壁垒（新能源汽车 =》 燃料电池 =》 交换膜）

市场规模

潜在市场规模 = 目标用户群数量 X 客单价 X 目标渗透率 （对于消费品，需要考虑复购率和频次）

市场规模 = 市场空间 * 当年渗透率（伴随市场会变的）

商业目标

商业目标是怎么产生？ 商业目标源于愿景，使命。

什么是增长的商业目标？
遵循商业指向和业务需求而制定的目标；在做增长的过程中，有明确的结果导向。

增长中的北极星指标：OMTM(One Metrics That Matters)

北极星指标怎么设定？

1. 能反映出你的产品的核心价值的指标
2. 能让用户价值得以体现的指标
3. 团队都能理解并息息相关的指标

北极星指标的拆解

输出型指标（负责最终产出的结果展示，更宏观、滞后性） VS 输入型指标（负责知道我们更细节的执行，更落地、引导型）

Output Metrics = N 个 Input Metric = N^2 Input Metrics = M X Task

公式化思维拆目标

1. 加法：指标指向的业务能否平行拆分为多个渠道来源
2. 乘法：指标能够拆为一个“量”，乘以一个“率”
3. 用公式化思维，对一些指标持续持续拆解下去

MECE分析问题：不重不漏

http://www.woshipm.com/pd/2663713.html
http://www.woshipm.com/marketing/3857526.html

核心：
支持快速试错的通用营销产品模型

营销体系至少包含：
效果广告投放、用户画像、标签系统、个性化推送、营销工具、分渠道流量效果统计

数字化营销体系要满足三个特点：
营销策略体系化、营销方式工具化、效果统计数据化。

真核心：
数据

营销手段：

比较简单的营销玩法：

领取优惠券
购物返现

一些比较复杂的、可自成体系的营销策略：

社交电商的裂变玩法
MGM（顾客介绍顾客）
淘客模式
外部渠道裂变

从各种底层学科中，我们可以学到什么？

我们可以学习到很多的概念，以及概念之间的联系。这些我们称之为知识。

学习更多的知识对于我们的生活，有两大作用：
1）提升我们的认知思维水平，也就说学了一门学科，能够升级你的思维。改变你对一个物体、一件事情甚至一个系统的看法。
2）提升我们某些方面的技能，例如心理学为平常的日常沟通提供了理论基础。

模型，是对世界某些事情的简化。当我们通过一个模型去描述一件事情，会阉割掉了很多冗杂的细节，让我们的思考更接近事情的本质。

拿互联网产品举个例子

我为什么要去学习一些互联网产品的文章呢？
我的目的是什么：
1）能够辅助产品同学做出更好的产品决策，让业务发展的更好
2）能够看清楚一个需求是否合理，他的收益是否足够高，从而可以将研发资源投入到投入产出比更高的需求中去

基于以上两个目的，
1）升级我的认知（之前我对产品的理解是错误的，最起码是不完整的，或者没有触及本质的）
2）总结出自己的做好产品的方法论
当你对互联网产品有了正确的思维认知以后

哲学

数学

心理学

元认知

物理学

熵与热力学

熵：状态数、可能性
封闭系统
耗散系统：需要为你的系统不停的注入信息、能量

伴随时间增加，封闭系统的熵总是会增加。

感知 + 选择 =》 逆熵

生命以逆熵为食

生物学