一些系统设计的讨论 FROM 1point3acres

CREATED 2021年12月19日 21:22

blacklist系统设计讨论

https://www.1point3acres.com/bbs/thread-829894-1-1.html

Read heavy write less system.

IPv4: 4 bits * 8 = 32 bits, IPv6: 4 bits * 4 * 8 = 128 bits.

It is recommended to store IPv4 as unsigned integer rather than string in MySQL database.

Write-through（直写模式）在数据更新时，同时写入缓存Cache和后端存储。此模式的优点是操作简单；缺点是因为数据修改需要同时写入存储，数据写入速度较慢。

Write-back（回写模式）在数据更新时只写入缓存Cache。只在数据被替换出缓存时，被修改的缓存数据才会被写到后端存储。此模式的优点是数据写入速度快，因为不需要写存储；缺点是一旦更新后的数据未被写入存储时出现系统掉电的情况，数据将无法找回。

[找工就业] [工作信息] 猴子也能懂的系统设计套路

https://www.1point3acres.com/bbs/forum.php?mod=viewthread&tid=776466&ctid=9

Functional Requirement
Non-functional requirement
Consistency - 是否会有数据不一致导致的问题？是否能接受部分数据copy不一致？电商类肯定就要strong consistency，like button能做到read your own write就可以了，后台型的服务eventual足矣。
Availability - 这个系统要有多可用，1年能承受多少down time。
Reliability - 是否可以接受一定的错误率+可以重试？数据的durability也可以这里谈下。
Performance/Throughput - 整体有多少用户量，大概率多少活跃用户，QPS大概有多少，peak factor是多少。
Read/Write ratio - 读为主还是写为主，用户使用pattern是否是非对称的（比如微博），读写是否有seasonal/recency pattern（比如读的都是最近写的），这个会让后面数据库选型讨论很方便。
Scalability - 这个和上面的吞吐的区别是，单机百万websocket和集群数万分布式事务都可以说scalable。
Misc - 这个就要看具体系统，比如金融交易这些，idempotency就很重要，要提到。比如用户facing的系统，latency就最好控制在200ms里。

Google Cloud - API 设计指南 https://cloud.google.com/apis/design