系统设计一些个人小结_代码007(未授权)

首页
互联网
正文

一些要记得的数字
关于时间
1天 =&g t; 86400秒
0.1% 的停机时间（即 99.9% 的可用性）就是一年停机时间8.77 小时。
0.01% 的停机时间（即 99.99% 的可用性）就是一年停机时间52.6 分钟。

关于存储
跟存储有关的K是1024，其它都是1000。下面的数字忽略1000和1024的区别。
1T =&g t; 10^12
1G => 10^9
1M => 10^6
1K => 10^3
1B => 10^9

一张 hard di sk 的MTTF (m e an time to failure) 是10到50年。一个 storage cluster (10000张硬盘)，可以估算平均大约1天坏一张硬盘。

关于数据库
MySQL 读写效率单机约1KQPS
Mon goDB – 读写效率单机约10QPS
Cassa nd ra – 读写效率单机约10QPS
Redis – 内存数据库 Ke y-Value 读写效率单机约100KQPS
Mem cache d – 内存数据库单机约1MQPS ?

假设一个数据库采用B+树，page=4KB, 4层，branch in g factor=500，可以存储256TB。

关于视频
参考这个链接 http://www.xnbu y.com/news/01/106.html

比特率大小×摄像机的路数=网络带宽至少大小；
CIF视频格式的所需带宽：512Kb ps(视频格式的比特率)×50(监控点的摄像机的总路数之和)=Kb ps=25Mbps(下行带宽)
即：采用CIF视频格式监控中心所需的网络下行带宽至少25Mbps
D1视频格式的所需带宽：1.5Mbps(视频格式的比特率)×50(监控点的摄像机的总路数之和)=75Mbps(下行带宽)
即：采用D1视频格式监控中心所需的网络下行带宽至少75Mbps
720P(100万像素)的视频格式的所需带宽：2Mbps(视频格式的比特率)×50(监控点的摄像机的总路数之和)=100Mbps(下行带宽)
即：采用720P的视频格式监控中心所需的网络下行带宽至少100Mbps
1080P(200万像素)的视频格式的所需带宽：4Mbps(视频格式的比特率)×50(监控点的摄像机的总路数之和)=200Mbps(下行带宽)
即：采用1080P的视频格式监控中心所需的网络下行带宽至少200Mbps

存储空间计算：
码流大小(单位：kb/s；即：比特率÷8)×3600(单位：秒；1小时的秒数)×24(单位：小时；一天的时间长)×30(保存的天数)×50(监控点要保存摄像机录像的总数)÷0.9(磁盘格式化的损失10%空间)=所需存储空间的大小(注：存储单位换算1TB=1024GB；1GB=1024MB；1MB=1024KB)
50路存储30天的CIF视频格式录像信息的存储空间所需大小为：64×3600×24×30×50÷0.9=8789.1GB≈9TB
50路存储30天的D1视频格式录像信息的存储空间所需大小为：192×3600×24×30×50÷0.9=.2GB≈26TB
50路存储30天的720P(100万像素)视频格式录像信息的存储空间所需大小为：256×3600×24×30×50÷0.9=.3GB≈35TB
50路存储30天的1080P(200万像素)视频格式录像信息的存储空间所需大小为：512×3600×24×30×50÷0.9=.5GB≈69TB

算法和系统设计的对应
算法里面用queue, 系统设计就用message queue (Redis, Kaf ka, Rab bitMQ等)，因为要持久化。
算法里面用hash set，系统设计就用KV的NonSQL数据库。

通常系统设计第一要求的是效率高，即延时低。而精度还是其次。
batch in g processing system su ch as Had oop ca res about th roug h put – th e number of rec o rds we can process per sec on d, o r the total time it tak es to run a job on a dataset of a ce rt ain size
online system cares more about the response time – the time b/w a client send in g a request and rec e i ving the response.

B-Tre e 和 LSM-Tr ee对比：

B-tree读快，LSM-Tr ee写快。
B-tree不好压缩, LSM-Tr ee易压缩

关于前端
HTML好比身体, CSS好比装饰用的衣服, JavaSc ript好比做什么动作。

关于协议和公司
Relational Database:
MySQL:
Postgr eSQL:
SQL Se r ver: Mic ro soft
Oracle: Oracle
NoSQL Database:
MongoDB: Amazon
Cassa ndra: Face book
Redis
Mem c ac he d
HBase: Google
BigTable: Google
TAO: Face book 开发的社交图谱数据库(Graphic database)
Ex p res so: Link edin 开发的document database
File Sy ste m:
EC2: Amazon
Message Queue (中间件Mi ddleware):
TIBCO:
WebSp here: IBM
webMeth ods:
RabbitMQ:
Ac ti veMQ
HornetQ:
(Ap ac he) Kaf ka
Binary encoding libraries (serialization):
Protocol Buf fe rs (protobuf): Google
(Ap ac he) Thrift: Face book, open source now.
(Ap ac he) Avro
Web Servi ce:
Aja x:

Acron y ms
2PC: two-p hase commit
2PL: two-p hase locking
3PC: three-phase commit
ACID: atomicity, consistency, isolation and durabi lity.
BASE: Basically Available, Soft state and Eventual consistency.
CAP: Consistency, Availability, Par tition Tolerance
CORBA: Com mon Object Request Bro ker Arc hitecture
COW: copy-on-write
CSS: Cascading Style Sheets (CSS) is a stylesheet language used to d escribe the presentation of a document written in HTML or XML.
DCOM: Distributed Component Object Mod el
EJB: Enterprise JavaBeans
ETL: Extract-Transform-Loa d (used in data warehouse)
gRPC: google RPC
JDBC: API
LSM: Log-Structured Merge Tree
MESI: //for c ache coherence b/w multiple cores.
MVCC: Multi-Vers ion Concurrency Contr ol
ODBC: API
OLAP: online analytic processing
OLTP: online transaction processing
OTA: (fi rm ware) over-the-air update
RDF: Resource Descript ion Framework (a mec hanism for different web sites to pub li sh data in a consistent format).
REST: Representational State Transfer. Based on HTTP.
RESTful: APIs based on REST
RMI: Java’s Remote Method Invo cat ion
RPC: remote procedure call
SIMD: Single Instruct ion Multi Data
SOA: Service Oriented Arc hitecture. a.k.a micro services
SOAP: Simple Object Access Protocol。基于XML
SSI: Serializable Snap shot Isolation
SSL:
SST: Sorted String Table
TLS:
WAL: write-ahead log
WSDL: Web Services Description Language