Skip to main content

· 9 min read

乍看书名以为是关于如何做笔记的工具书,后面发现重点是讲写作思维方式,整体内容上比看之前的预期好很多。卡片盒写作法是卢曼杰出学术成就的生产力来源,他在长达 30 多年的研究中出版了 58 本著作以及数百篇文章。书中主要是论述如何通过卡片笔记的方法进行写作,也顺便解答了我的几个问题:

  • 为什么无法记住阅读后的大部分内容,隔一段时间还是会在同一个地方被反复醍醐灌顶?主要是人脑的容量有限,只会暂存短期内认为最重要的事情(蔡格尼克效应),不借助外部存储很快会丢失。前几天刚好也看到艾宾浩斯遗忘曲线也证实知识遗忘是学习过程中的普遍现象,可以通过科学复习方法来减少遗忘比例。
  • 为什么写作这么难?为什么会陷入一直想写但无从下手的循环?书中的提到很重要的观点:写作不应该从空白屏幕开始,而是需要从阅读中刻意积累观点和论据,将写作过程变成自下而上的过程。一直将不知道写什么归因为缺少足够的输入,虽然该观点是对的但又过于宽泛。现在我会理解为是缺少刻意的输入和积累,选择某个方向之后,需要刻意去收集和阅读相关方向的信息,暂且放下不相关的输入。
  • 为什么有笔记但仍然对知识记忆帮助不大?不管是重点划线还是空白处记录想法,过程中缺失了思考或者关联,最终也只是得到一堆不会再看的笔记。作者提到卢曼的卡片笔记最重要的是分类、关联以及定期整理,丢弃掉临时或者过期的观点。

这本书对于我自己最大的帮助在于阅读思维的变化, 也促使我写下了第一篇读书笔记。当然,能否真正带来写作上的改变,需要留给时间来回答。我十分喜欢里面关于读书的观点: 「读书不是为了积累知识而是形成自己的思维框架,并使用新观点和事实对过往的经验提出质疑」。我们不是复读机,不必为了可以背出某个名人的语句而读书,而应该是纯粹为了形成自己的思考方式。具备自己的思考和辨别能力,而不是受某种权威或者舆论的引导。以下是个人认为值得分享的几个观点。

写作很重要

书中引用卢曼的: 「不写,就无法思考」 来说明写作的重要性。很多人都意识到了写作表达的重要性,但能够坚持践行的人并不多。主要是过往教授的写作方式包含很多写作指南书籍都是至上而下,习惯于围绕着某个主题展开论述,缺少了最关键的论据收集以及积累的过程。以至于需要从容量有限的大脑里搜索和提取观点,将写作变成痛苦的脑暴过程。而卢曼的卡片笔记写作法核心则是相反,提出写作不应该是空白纸开始,而是通过大量阅读以及积累观点这种自下而上的过程。遇到有价值的观点,用自己的语言写下来思考,写作时只需将这些过往的观点聚合到一起。反过来,要想要讨论某个话题,重要的是收集相关材料进行阅读和思考,而不是写作的过程或者工具。另外,书中举了很多次费曼的例子来强调关联的重要性,零散的知识点很难记住,而关联之后更加容易。也可以同时复盘之前哪些观点是一致或者相悖,写作就是关联的过程,可以通过写作不断更新自己的理解和思考。

确认偏差

在保持开放心态的章节里面提到了 确认偏差 这个概念,大体的意思是人潜意识会被熟悉或感觉良好的事物所吸引,剔除那些有违我们认知的事物。确认偏差会让我们无意识自动进入搜集周围有利于结论的数据,从而干扰学习和思考。写作也是一样,在寻找论据时需要克服确认偏差的干扰,避免无意识只收集对论点有利的证据。 对于写作来说,克服的方式可以将寻找证实性的事实变成收集所有相关信息,而不管它支持什么论点。书中也引用了 Charles Darwin 如何处理确认偏差的方式: 遇到与自己结论相反的事实或者观点时立即把它们记下来,因为这些事实和观点更加容易被忽略。

「亚马逊反向工作法」 书中的招聘章节也提到这个概念,由于确认偏差导致招聘者倾向于关注他人确认的正面信息,而忽略负面和矛盾的信息,最终导致 "群体思维"。举的例子就是面试官之间交流一旦给予正面反馈,会导致后续面试过程中无意识尝试寻找候选人这些优点,从而忽略了候选人存在的缺陷。很多公司的招聘流程上都存在类似的问题,只是可能没有意识到而已,一旦意识到之后改变就变得很容易。

总结

写作最重要都是个人的理解和思考,不管多好的工具都是为了更系统化的思考。受限于人脑的存储容量,需要通过笔记的方式将记忆 offloading 到外部存储以减少知识遗忘。卡片笔记写作法本身并没有魔法,如果有,应当所有看过这本书的人都能够变成长期的写作者,它最重要的作用是改变了写作思维,让我们意识到写作不应该从零开始而是日常的理解和思考。另外,对于专题写作(比如论文)也是一样,写作过程不是重点,而是围绕专题阅读资料过程中个人的理解和思考。当然,最为重要的还是实践,只有真正到水里才能学会游泳。

欢迎扫码关注 hulk 个人微信公众号,一起学习和交流:

img

· 12 min read

大部分开发对 Bitmap 应该都不陌生,除了作为 Bloom Filter 实现的存储之外,许多数据库也有提供 Bitmap 类型的索引。对于内存型的存储来说,Bitmap 只是一个特殊类型(bit)的稀疏数组,操作内存不会带来读写放大问题(指的是物理读写的数据量远大于逻辑的数据量), Redis 就是在字符串类型上支持 bit 的相关操作,而对于 Kvrocks 这种基于磁盘 KV 实现的存储则会是比较大挑战,本篇文章主要讨论的其实是「基于磁盘 KV 实现 Bitmap如何减少磁盘读写放大」

· 16 min read

Kvrocks 是基于 RocksDB 之上兼容 Redis 协议的 NoSQL 存储服务,设计目标是提供一个低成本以及大容量的 Redis 服务,作为 Redis 在大数据量场景的互补服务,选择兼容 Redis 协议是因为简单易用且业务迁移成本低。目前线上使用的公司包含: 美图、携程、百度以及白山云等,在线上经过两年多大规模实例的验证。

项目核心功能包含:

  • 兼容 Redis 协议
  • 支持主从复制
  • 支持通过 Namespace 隔离不同业务的数据
  • 高可用,支持 Redis Sentinel 自动主从切换
  • 集群模式 (进行中,预计在 7-8 月份完成)

GitHub地址:https://github.com/bitleak/kvrocks

· 7 min read

美图 PHP 业务团队在使用 php-memcached 扩展陆陆续续遇到一些隐蔽的 ”坑”,而这些坑在 php-memcached 也是比较容易踩到。其中有如 TCP_NODELAY 这类常见的坑,也有一些 php-memcached 本身设计带来的问题。这里分享出来希望可以给遇到类似问题或者正在坑里的同学带来一些帮助。

· 6 min read

tcpkit 是支持用 lua 脚本分析网络数据包的工具,附带简单协议解析(Redis/Memcached)和延时统计。最早开发 tcpkit 主要原因是经常需要通过网络包来分析资源慢请求问题,在数据包量比较大的场景下人肉分析会浪费比较时间,所以希望可以通过编码的方式来分析这类问题。从开发至今已经帮助我们团队以及美图 DBA 定位无数的线上问题,之前甚至通过 tcpkit 找到了 BCM 网卡驱动到 kernel 偶发产生几百毫秒延时问题。

Github 地址: https://github.com/git-hulk/tcpkit

· 13 min read

lmstfy(Let Me Schedule Task For You) 是美图架构基础服务团队在 2018 年初基于 Redis 实现的简单任务队列(Task Queue)服务,目前在美图多个线上产品使用接近两年的时间。主要提供以下特性:

  • 任务具备延时、自动重试、优先级以及过期等功能
  • 通过 HTTP restful API 提供服务
  • 具备横向扩展能力
  • 丰富的业务和性能指标

Github 项目地址: https://github.com/meitu/lmstfy

· 11 min read

前天晚上不经意间在 youtube 上面看到 Redis 作者 SalvatoreRedisConf 2019 分享,其中一段展示了 Redis 6 引入的多线程 IO 特性对性能提升至少是一倍以上,内心很是激动,迫不及待地去看了一下相关的代码实现。

目前对于单线程 Redis 来说,性能瓶颈主要在于网络的 IO 消耗, 优化主要有两个方向:

  1. 提高网络 IO 性能,典型的实现像使用 DPDK 来替代内核网络栈的方式
  2. 使用多线程充分利用多核,典型的实现像 Memcached

· 15 min read

美图在 2017 年下半年开始计划做 Redis/Memcached 资源 PaaS 平台,而 PaaS 化之后面临一个问题是如何实现资源缩容/扩容对业务无感,为了解决这个问题,美图技术团队于 17 年 11 月引入 twemproxy 作为资源网关。

但是长期的实践中,其开源版本不能完全适应美图的实际情况,其主要存在单线程模型无法利用多核,性能不佳;配置无法在线 Reload ;Redis 不支持主从模式;无延时指标等问题,所以美图技术团队对其进行了相应的改造。我们基于之上实现了多进程以及配置在线更新的功能,同时增加了一些延时的相关监控指标。

本文将为大家详细讲解 twemproxy 实现以及相应地改造,希望能给其他的技术团队提供一些可以借鉴的经验。

· 6 min read

对于 Redis 这种单线程模型的服务来说,一些耗时的命令阻塞其他请求是个头痛的问题。典型的命令如 KEYS/FLUSHALL/FLUSHDB 等等,一般线上也会禁用这些会遍历整个库的命令。而像 DEL/LRANGE/HGETALL 这些可能导致阻塞的命令经常被工程师忽视,这些命令在 value 比较大的时候跟 KEYS 这些并没有本质区别。

Redis 4.0 开始针对 DEL/FLUSHALL/FLUSHDB 做了一些优化。