最新 | 最热门 | 最高评价
---

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

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

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

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

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

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

+1  企业级SSD硬盘fsync速度

Tag: 计算机架构
ideawu 发于 2021年08月27日 20:42 | 点击: 1438 | 展开摘要
小数据测试, 以便对硬盘 fsync 的速度有一个大概的了解. 结果:

rate
latency
备注

4044/s
0.247ms
Intel SATA SSD

19720/s
0.051ms
Intel NVMe SSD

结论: SATA 盘的 QPS 是 4000, NVMe 的 QPS 是 20000.

如果要开发一个分布式 KV 数据库, 那么对于每一个客户端请求, 至少进行 1 次日志 fsync. 为了提高吞吐量(QPS), 日志模块必须进行 batc

查看全文: http://www.udpwork.com/item/18118.html
7

+3  生产者消费者模式的系统性能分析方法

Tag: 计算机架构
ideawu 发于 2021年08月21日 12:04 | 点击: 1685 | 展开摘要
前一篇文章介绍了生产者消费者编程模式, 一种非常流行且强大的编程模式. 本文将分析采用这种模式的系统的性能分析方法, 以做性能优化.

系统性能分析主要关注这几个指标:

qps/rps(queries per second, requests per second) - 每秒处理请求数, 也即吞吐量(throughput), 一般也称为处理速度的大小, 通俗也称为性能

latency - 单次请求处理的耗时. 一般关注平均值(avg), 最大值(max), 最小值(min

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

+0  生产者消费者编程模式

Tag: 计算机架构
ideawu 发于 2021年08月15日 09:42 | 点击: 537 | 展开摘要
相信很多人都知道"生产者消费者"编程模式, 也使用过这种模式, 但是, 可能只是本能不自觉地使用过, 未必对这种模式有清晰和深刻的理解. 特别是级联生产者消费者模式, 更是强大无比. 很多人可能没有意识到, Golang 语言的核心思想正是生产者消费者模式, 也即 go routine + channel.

假设有一个功能, 处理某个任务需要进行3个步骤, 那么代码可以这样写:

func worker(t *Task) {
step1(t)
step2(t

查看全文: http://www.udpwork.com/item/18113.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  面向全球的应用的系统架构

Tag: 分布式 | 高性能Web架构
ideawu 发于 2021年04月17日 18:25 | 点击: 938 | 展开摘要
某些产品是面向全球用户的, 所以会在全球多个机房部署业务进程(Service)和数据库(Database). 这带来了所谓的数据一致性问题. 以用户加好友功能作为例子:

用户 A 在中, 在 App 中向用户 B 发送了好友申请. 用户 B 在美国, 打开 App 刷新, 没有看到有任何未处理的好友申请…

这是一个非常典型的例子. 我们仔细分析一下问题出在哪.

首先, 用户 B 刷新 App, 没有看到任何好友申请, 算是一个问题吗? 看不到好友申请, 本身不算问题,

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

+0  港股实时行情系统设计

Tag: 网络编程 | 高性能Web架构
ideawu 发于 2018年07月26日 16:24 | 点击: 1903 | 展开摘要
做一下记录。

做了一个可靠传输层，优点是层次分明，缺点是当丢包时价格更新不及时。可以优化成只重传不排序，Aggregator 区分是否是最新包，不是最新包则不更新最新价。

对外提供推和拉接口，两种都有适用场景，不能只提供一种。Query Server 采用 HTTP 协议，Push Server 可以用 WebSocket 协议。

把图改成 stack 形式。

Related posts:
为什么iComet比nginx-push-stream-module更好?

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

+0  流行的rpc框架benchmark 2018新春版

Tag: 架构
鸟窝 发于 2018年02月01日 17:22 | 点击: 2541 | 展开摘要
随着公司规模的扩大，以及业务量的激增，单体应用逐步演化为服务/微服务的架构模式， 服务之间的调用大多采用rpc的方式调用，或者消息队列的方式进行解耦。几乎每个大厂都会创建自己的rpc框架，或者基于知名的rpc框架进行改造。

目前, rpc框架主要沿着两条路线发展，一个是目标为了跨语言，服务端可以用不同的语言实现，客户端也可以用不同的语言实现，不同的语言实现的客户端和服务器端可以互相调用。很显然，要支持不同的语言，需要基于那种语言实现相同协议的框架，并且协议设计应该也是跨语言

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

+0  Kafka的复制机制

Tag: kafka | 架构
鸟窝 发于 2017年11月03日 10:21 | 点击: 2084 | 展开摘要
最近在设计一个多分区多副本的消息系统，以前对kafka有一些了解，在阅读了阿里的RocketMQ、小米的Pegasus等分布式系统后，再仔细阅读的kafka的复制设计，整理出本篇文档，可以和其它系统做一个对比。

Kafka是一种高吞吐量的分布式发布订阅消息系统，有如下特性：

通过O(1)的磁盘数据结构提供消息的持久化，这种结构对于即使数以TB的消息存储也能够保持长时间的稳定性能。

高吞吐量：即使是非常普通的硬件Kafka也可以支持每秒数百万的消息。

支持通过Kafka

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

+0  [转]设计一个容错的微服务架构

Tag: 架构
鸟窝 发于 2017年08月23日 13:52 | 点击: 2728 | 展开摘要
原文: Designing a Microservices Architecture for Failure
翻译: 设计一个容错的微服务架构 by Jason Geng

微服务架构使得可以通过明确定义的服务边界来隔离故障。但是像在每个分布式系统中一样，发生网络、硬件、应用级别的错误都是很常见的。由于服务依赖关系，任何组件可能暂时无法提供服务。为了尽量减少部分中断的影响，我们需要构建容错服务，来优雅地处理这些中断的响应结果。

本文介绍了基于RisingStack 的 No

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

+0  API设计原则 – Qt官网的设计实践总结

Tag: C/C++语言 | 技术读物 | 程序设计 | 系统架构 | API | api-design | API设计 | C++ | Coding | Design | Programmer
李 鼎 发于 2017年07月25日 14:16 | 点击: 2172 | 展开摘要
（感谢好友 @李鼎 翻译此文）

原文链接：API Design Principles – Qt Wiki

基于Gary的影响力上 Gary Gao 的译文稿：C++的API设计指导

译序

Qt的设计水准在业界很有口碑，一致、易于掌握和强大的API是Qt最著名的优点之一。此文既是Qt官网上的API设计指导准则，也是Qt在API设计上的实践总结。虽然Qt用的是C++，但其中设计原则和思考是具有普适性的（如果你对C++还不精通，可以忽略与C++强相关或是过于细节

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

+0  从Gitlab误删除数据库想到的

Tag: 技术新闻 | 程序设计 | 系统架构 | Design | Gitlab | High Availability | Programmer | 分布式 | 程序员
陈皓 发于 2017年02月02日 16:11 | 点击: 2941 | 展开摘要
昨天，Gitlab.com发生了一个大事，某同学误删了数据库，这个事看似是个低级错误，不过，因为Gitlab把整个过程的细节都全部暴露出来了，所以，可以看到很多东西，而对于类似这样的事情，我自己以前也干过，而在最近的两公司中我也见过（Amazon中见过一次，阿里中见过至少四次），正好通过这个事来说说一下自己的一些感想和观点吧。我先放个观点：你觉得有备份系统就不会丢数据了吗？

事件回顾

整个事件的回顾Gitlab.com在第一时间就放到了Google Doc上，事后，又发了

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