最新 | 最热门 | 最高评价
^..^

+0  记一次关于系统性能的有趣讨论

Tag: IT技术和评论 | 计算机架构
ideawu 发于 2021年09月04日 10:29 | 点击: 1699 | 展开摘要
有个同事问我:"你开发的分布式数据库系统, 如何避免 scan 扫描操作返回了 pending 事务状态的数据?"

我说:"把数据扫描出来, 然后逐个判断过滤掉 pending 状态的数据."

我感到奇怪, 对于他的问题, 解决方案非常显然啊. 解决方案非常直观, 兵来将挡水来土掩, 我相信他也能想到, 不想要的数据当然要剔除掉, 否则呢? 那么, 他的问题的点在哪?

没错, 他接着问了:"我 scan 的时候只想返回 key, 但是, 要判断状态, 是不是还得去读取

查看全文: http://www.udpwork.com/item/18148.html
---

+0  程序设计核心原则: 直观

Tag: IT技术和评论 | 算法
ideawu 发于 2021年08月07日 09:41 | 点击: 549 | 展开摘要
好的代码应该是直观的, 简单的. 直观就是"所思就所写", 想的是什么样就要把代码写成什么样子, 不要七拐八绕.

例如, 在做结构设计和流程设计时, 我们分析出某个功能流程应该这样做:

先做步骤1, 然后做步骤2.

什么是程序设计? 程序设计就是流程, 是串行化, 是先后顺序. 所以, 文档设计完毕之后, 必须写下这样的代码:

step1();
step2();

没错, 就是非常直观的两个函数调用语句, 一眼就能看出有先后顺序, 先 1 后 2. 但是, 初学者往往

查看全文: http://www.udpwork.com/item/18115.html
---

+0  程序员的必备品质

Tag: IT技术和评论
ideawu 发于 2021年07月27日 21:31 | 点击: 682 | 展开摘要
1. 判断力

在开发复杂系统时, 有判断力(决断力), 懂得去选择简单正确的架构和方案, 先把系统做出来. 大部分的程序员并没有这种思考决断能力. 如果让他们自己做决策, 他们会陷入思维混乱, 面对多个选项时优柔寡断. 几乎每一次内心将要下决断, 都会被"性能优化"思想给驳回.

2. 持续改进能力

虽然大部分程序员没有开发一个完整系统的能力, 但是, 仅仅用最简单的方案把系统做出来, 还不是终点. 只要方案足够简洁, 第一版一般能满足短期需求, 也许不能满足. 但业务的

查看全文: http://www.udpwork.com/item/17980.html
---

+0  复杂软件系统开发的第一原则: KISS

Tag: IT技术和评论 | 计算机架构
ideawu 发于 2021年07月23日 21:44 | 点击: 899 | 展开摘要
俗话说:

Keep It Simple, Stupid!

由于大部分新手程序员在从学生转换成为工程师之前, 都经过所谓的"算法"编程训练, 特别是不少人还主动进行大量的"刷题"行为, 因此, 对"性能"的追求被潜移默化地植入了所有程序员的基因, 这就造成了程序员往往把细节上的所谓性能优化放到第一优先的位置.

这种片面追求细节性能, 从而缺少大局观的思维, 其实是非常错误的. 比如 C++ 程序员, 几乎把性能优化等同于减少内存拷贝和无锁(lock free), 认为内存

查看全文: http://www.udpwork.com/item/17983.html
1

+1  100行代码的压缩前缀树: 50% smaller

Tag: algo | memory | succinct | trie | bitmap
张炎泼(xp) 发于 2021年02月01日 08:00 | 点击: 944 | 展开摘要
这文介绍一个压缩前缀树实现的sorted set(github: succinct.Set), 区区95行代码, 包含了一组完整的功能:

用 前缀树 存储一个排序数组, 去掉指针, 压缩掉50%的空间;
例如在本文的例子中, 存储2.4MB的200万个单词, 只需要1.2MB.

创建: 从key列表创建一个压缩的前缀树;

查询: 支持Has() 操作来查询1个key是否存在;

优化: 通过索引来加速 bitmap 的操作, 将较大的 bitmap 操作优化到O(1)的

查看全文: http://www.udpwork.com/item/17474.html
^..^

+0  常见分布式应用系统设计图解（十三）：短网址系统

Tag: System and Architecture | 图解笔记 | 应用系统 | 短网址 | 系统设计
四火 发于 2020年12月29日 07:46 | 点击: 685 | 展开摘要
短网址系统可能是最常见的分布式系统设计问题之一了，本身从业务需求上说，读远多过写，而且数据结构确定且简单，数据量小，还易于使用缓存，因此本身难度在分布式系统的问题里面算是比较低的。另外，这个系统本身 “分布式” 的特性也比较弱，而且从组件图的角度来说，没有多少是 “可画的” ，因此之前也就没有介绍它。不过后来我改变想法了，我觉得还是可以总结总结，特别是可以把一些相关的特殊需求考虑进去。

短网址服务就像是 bit.ly 这样的，给一个长长的 URL，它给你吐出一个较短的 UR

查看全文: http://www.udpwork.com/item/17816.html
^..^

+0  常见分布式应用系统设计图解（十二）：证券交易系统

Tag: System and Architecture | 交易系统 | 图解笔记 | 应用系统 | 系统设计 | 股票
四火 发于 2020年12月27日 02:09 | 点击: 768 | 展开摘要
这篇讲的是证券交易系统，这类系统包含的内容很多，但是我们还是把目光放在核心的交易部分，比如说股票交易。在某个可交易时间，如果卖家 A 要以至少 y 的价格卖掉股票 x，卖家 B 愿以至多 y 的价格买入股票 x，那么这个交易就可以发生。

虽说是交易系统，但是它和任何一个支付平台的交易系统有着显著的不同，它的核心是一个竞价匹配的机制，而非货币支付的机制，简单地说，这个机制包含了这样四个步骤：

挂单（可以是买单，也可以是卖单）
匹配（或者叫做撮合）
成交
清算

从非功能的角

查看全文: http://www.udpwork.com/item/17817.html
---

+0  Go 编程模式：k8s Visitor 模式

Tag: Go 语言 | 程序设计 | 编程语言 | design pattern | Go | golang | Kubernetes | Visitor Pattern
陈皓 发于 2020年12月26日 19:25 | 点击: 775 | 展开摘要
本篇文章主要想讨论一下，Kubernetes 的 kubectl 命令中的使用到到的一个编程模式 – Visitor（注：其实，kubectl 主要使用到了两个一个是Builder，另一个是Visitor）。本来，Visitor 是面向对象设计模英中一个很重要的设计模款（参看Wikipedia Visitor Pattern词条），这个模式是一种将算法与操作对象的结构分离的一种方法。这种分离的实际结果是能够在不修改结构的情况下向现有对象结构添加新操作，是遵循开放/

查看全文: http://www.udpwork.com/item/17487.html
^..^

+0  用markdown写知乎文章的完美解决方案

Tag: toolkit | zhihu | 知乎 | markdown
张炎泼(xp) 发于 2020年12月24日 08:00 | 点击: 706 | 展开摘要
习惯了用markdown做各种笔记或创作, 想要分享到知乎的时候,
发现知乎对文章导入markdown的支持并不很好, 不支持表格, 需要公开可访问的url的图片,
以及知乎私有的公式编辑功能.

于是有了这样一个工具 md2zhihu , 将markdown文档直接转换成可以导入到知乎的格式.
主要做3项转换: 公式, 表格和图片.

例如以下 markdown 源码:

| Data size | Data Set | gzip size |

查看全文: http://www.udpwork.com/item/17476.html
^..^

+0  常见分布式基础设施系统设计图解（七）：分布式实时流处理系统

Tag: System and Architecture | streaming | 图解笔记 | 基础设施 | 实时 | 系统设计
四火 发于 2020年11月20日 07:11 | 点击: 625 | 展开摘要
今天这篇是关于实时流处理（real-time stream processing）的，这一类的系统这几年比较多了，但相对而言并没有之前提到的几类基础设施系统常见。为什么说这类系统如今更为常见呢？因为一般说来，或者说曾经有一个普遍的认知，就是 throughput 和 latency 难以兼得的事实：

同步系统适用于响应实时性要求高的请求，处理实时性要求高的数据，速度快，处理过程中关注的数据粒度小，吞吐量也相对受限；
异步系统适用于响应实时性要求低的请求，处理实时性要求低的数

查看全文: http://www.udpwork.com/item/17818.html
---

+0  常见分布式应用系统设计图解（十一）：数据监控系统

Tag: System and Architecture | 图解笔记 | 应用系统 | 监控系统 | 系统设计
四火 发于 2020年11月18日 05:37 | 点击: 527 | 展开摘要
这篇是讲数据监控系统的，常见的包括 Datadog 和 Prometheus 等等。一个比较完整的数据监控系统要包括数据采集和数据展示两个部分。在此基础上，还可以具备告警和其它数据处理的功能。

对于监控的数据， 通常包括两类，一类是操作系统层面的数据，比如 CPU、内存、IO 等等；还有一类是应用相关的数据，这些数据就具备明确的业务意义了。

大体上，图中虚线表示控制流，而实现表示实际的统计数据流向。
用户通过 Web UI 来查看数据、定义规则，这些元信息存储在图中上方的

查看全文: http://www.udpwork.com/item/17819.html
---

+0  常见分布式应用系统设计图解（十）：电商秒杀系统

Tag: System and Architecture | 图解笔记 | 应用系统 | 电商 | 秒杀 | 系统设计
四火 发于 2020年11月17日 03:11 | 点击: 553 | 展开摘要
这篇是关于电商平台秒杀系统的。

首先，我觉得 “秒杀” 是一个中国色彩浓重的词，这样的概念在西方电商系统中也有，但只有在中国，本来业务量就已经如此之巨大了，还将其如此发扬开来。因此顶尖的秒杀高并发场景，还真是基本上只有在中国的电商平台系统中，才能见得到。

其次，我觉得对于系统设计的学习，电商秒杀系统这样的极致，即便再精彩，还是应当放在第二位的。扎扎实实地把常规的高并发系统设计做好，才是最重要的。因为无论秒杀系统使用怎样的特殊技巧和手段，高并发分布式系统才是一个秒杀系统工作

查看全文: http://www.udpwork.com/item/17820.html
|<<<1234567>>>| 一共69页, 828条记录