小曹不可爱吗：Redis特点 1. 丰富的数据类型 (string, hash, set ,zset, list 等) 2. 读写性能优异 3. 单线程原子性 4. 可持久化 aof/rdb 5. 支持pub/sub 订阅发布模式 6. 高可用方案：哨兵机制 分布式一致性：redis主从为异步复制模式，一致性无法保证 (多节点数据一致性强依赖网络延迟) 主要适用场景：队列, 缓存，分布式session，等非强一致性需求 Etcd特点 1. 分布式一致性：基于raft协议，写入数据需要多数节点应答，确认后才会将数据返回给客户端。 2. 复制模式：基于日志复制 3. 主要适用场景：配置管理、服务发现 4. 易用性方面：Etcd 提供了HTTP API 总结：配置管理/服务发现 需要高可用和强一致性，从上面可以看出，Redis并不具备该特性。Redis有着优秀的并发吞吐能力，在web应用中，Redis大多数当缓存，队列使用，缓解数据库压力。 两者区别： Etcd的红火来源于K8s用Etcd做服务发现，而Redis的兴起则来源于Memcache缓存本身的局限性。 Etcd是一种分布式存储，更强调的是各个节点之间的通信，同步，确保各个节点上数据和事务的一致性，使得服务发现工作更稳定，本身单节点的写入能力并不强。 Redis更像是内存型缓存，虽然也有Cluster做主从同步和读写分离，但节点间的一致性主要强调的是数据，并不在乎事务，因此读写能力很强，Qps甚至可以达到10万+ 两者都是k-v存储，但Redis支持更多的存储模式，包括KEY，STRING，HMAP，SET，SORTEDSET等等，因此Redis本身就可以完成一些比如排序的简单逻辑。而Etcd则支持对Key的版本记录和txn操作和Client对Key的watch，因此适合用做服务发现。 日常使用中，Etcd主要还是做一些事务管理类的，基础架构服务用的比较多，容器类的服务部署是其主流。而Redis广泛地使用在缓存服务器方面，用作Mysql的缓存，通常依据请求量，甚至会做成多级缓存，当然部分情况下也用做存储型Redis做持续化存储。

满帮内推：都说香港房价高，人人住鸽子笼。可是深圳的公屋比例比香港还低，南山区的房价已经赶上深圳湾大桥对岸的元朗了，然而香港洗碗阿姨的工资都比深圳的中位数高40% 这是毕业生考虑留不留深圳的问题吗，这是深圳考虑留不留毕业生的问题……

牛客司机：忽然想到在我小的时候，爷爷教我一招（ps:爷爷是上世纪60年代大学生），每天晚上他都会在睡觉的时候根据时间先后顺序回想一下今天发生的所有事情，脑袋里就像过电影一样。这样做不仅帮助自己把今天做的事儿做一个总结，同时真的有助于睡眠，一般我还没回忆完就已经睡着了。 但也有不适用的时候，在我工作之后，比如现在我回帖的时候就已经凌晨1:30了，因为工作上有很多事儿要处理到比较晚，所以躺下不困的时候，就会起来继续干活，等困了立马睡。

小曹不可爱吗：我们生活中的数据总体分为两种：结构化数据和非结构化数据。 结构化数据：指具有固定格式或有限长度的数据，如数据库，元数据等。 非结构化数据：指不定长或无固定格式的数据，如 互联网数据、邮件，word文档等。 对非结构化数据顺序扫描很慢，对结构化数据的搜索却相对较快，那么把我们的非结构化数据想办法弄得有一定结构不就行了吗？这就是全文检索的基本思路，也就是将非结构化数据中的一部分信息提取出来，重新组织，使其变得有一定结构，然后对此有一定结构的数据进行搜索，从而达到搜索相对较快的目的。这部分从非结构化数据中提取出的然后重新组织的信息，我们称之索引 。 非结构化数据又一种叫法叫全文数据。 按照数据的分类，搜索也分为两种： 1. 对结构化数据的搜索： 如对数据库的搜索，用SQL语句。再如对元数据的搜索，如利用windows搜索对文件名，类型，修改时间进行搜索等。 2. 对非结构化数据的搜索： 如用Google和百度可以搜索大量内容数据。 对非结构化数据也即全文数据的搜索主要有两种方法：顺序扫描法和反向索引法。 1. 顺序扫描法：所谓顺序扫描法，就是顺序扫描每个文档内容，看看是否有要搜索的关键字，实现查找文档的功能，也就是根据文档找词。 2. 反向索引法：所谓反向索引，就是提前将搜索的关键字建成索引，然后再根据索引查找文档，也就是根据词找文档。 这种先建立索引，再对索引进行搜索文档的过程就叫全文检索(Full-text Search) 。 全文检索的流程分为两大流程：索引创建、搜索索引 索引创建：将现实世界中所有的结构化和非结构化数据提取信息，创建索引的过程。 搜索索引：就是得到用户的查询请求，搜索创建的索引，然后返回结果的过程。

肖先生~：物理层，数据链路层，网络层，传输层，会话层，表示层和应用层 物理层：建立、维护、断开物理连接 数据链路层：该层的作用包括了物理地址寻址，数据的成帧，流量控制，数据的检错，重发等。该层控制网络层与物理层之间的通信，解决的是所传输数据的准确性的问题。为了保证传输，从网络层接收到的数据被分制成特定的可被物理层传输的帧。帧是用来移动数据的结构包，它不仅包括原始数据，还包括发送方和接收方的物理地址以及纠错和控制的信息。其中的地址确定了帧将发送的位置，纠错和控制信息则保证帧的准确到达。如果传送数据的过程中，接收点检测到数据有错误，就通知发送方重新发送这一帧。 网络层：主要功能是讲网络地址翻译成对应的物理地址，并决定如何将数据从发送方路由到接受伐，他解决的是寻址和优化传输路径的问题。 网络层通过综合考虑发送优先权，网络拥塞程度，服务质量以及可选择路由的花费决定从一个网络中节点A到另一个网络中节点B的最佳路径。在网络中，“路由（router）”基于编址方案，使用模式以及可达性来指引数据的发送，网络层负责在原机器和目的机器之间建立他们所使用的路由 网关:网间连接器,协议转换器,网关在网络层上实现网络互连,对接收到的信心重新打包,以适应目的系统的需求 解决阻塞的办法:数据分组,编号传输出去;然后接收到数据后排序重组解码;选择最优路径;丢包也是发生在网络层. 传输层：按照网络能处理的最大尺寸将教程的数据包进行强制分割，发送方节点的传输层将数据分割成交小的数据片，同时对每一个数据片安排一序列号，以便数据到达接收方的传输层时能以正确 的顺序重组，该过程称为排序。 会话层：会话层负责在网络中的两节点之间建立，维持和终止通信，在这层协议中，解决节点链接的协调和管理问题 会话层的功能包括：建立通信链接，保持会话过程通信连接的畅通。 表示层：表示层是应用程序和网络之间的翻译官。在表示层，数据需要按照网络所能理解的方案的进行格式化。这种格式化因为使用网络的类型的不同而不同。表示层管理数据的加密和解密，例如银行账户，账户数据发送前加密，接受的时候对账户进行解密。 应用层：负责提供数据接口标准，提供的服务包括文件的传输，文件的管理以及电子邮件的信息处理

肖先生~：首先让我们先来思考下，运营是什么？ “一切围绕产品或服务进行人工干预的过程都叫做运营”。 而“运营”这个词，从字面来看，无非是“运作”+“营收”，通过利用各种的运作手段，获取持续的营收。 那再来思考下第二个问题，运营应该为什么负责？ “运营工作，核心目的仍然是为流量负责”。 是时候思考第三个问题了，流量是什么？ 流量是什么呢？我们都知道随着用户的碎片时间越来越细碎，各家移动互联网厂商都想在其中分一杯羹，谁能够获得更多的用户碎片时间，谁就能获得更高的曝光，吸引更多的眼球与更多的资源（资本）。 换言之，这里我们聊到的“积累流量势能，进行利用”，就是在运营里面经常说到的“留存”，至于用户留下来之后到底是以此制作UGC内容产生推广，以此作为基础产生对应的用户复购都是下一步的工作，任何功能的设计、内容的制造、活动的参与、问题的解决，都需要在完成了“留存用户”这一步之后才有意义。 既然我们已经明确了运营工作的核心是为流量负责，明确了产品运营这一岗位的职责是通过各种各样的手段获取流量与营收，那么我们也就不难发现，运营行业中的各个岗位，不同的细分工种都是在针对一个具体的关于流量的目标而努力。 什么是具体的目标？ 有的同学看到这里，可能对这句话会产生一些疑问“我的工作内容是负责公司主体下的微信公众号撰写/抖音短视频编辑/运营专属的用户社群，这和具体的流量工作有什么关系呢？” 很简单，就像我们所说的“不同细分工种会针对具体关于流量的目标而努力”，这里具体关于流量的目标其实是经过了层层拆解得出的。 换言之，目标拆解就是一句话“在规定的时间内把规定的事情做到规定的数量”。 如何针对目标做对应的拆解与执行？ 拆解目标并执行的方法很多，不同行业不同工种都会有不同的方法，而在这里我想想你介绍一种最简单的方法——PDCA。 什么是PDCA？ 简单来说，PDCA只有简单的四步，计划（Plan）→执行（Do）→检查（Check）→调整（Action）。 这四步看起来很简单，但它的应用是一个永无止境的过程，认真履行 PDCA 的人会发现 PDCA 适用于所有问题、所有对象。 下面我们解释下如何通过PDCA进行目标的拆解。

养猪状元✔：带什么产品合适，什么内容吸引人，如何把产品更好地融入内容中

养猪状元✔：淘宝的覆盖的收入群体、用户年龄更均匀。京东用户的平均年龄会偏大，80后最多，京东用户消费水平更高，注重生活品质。