26 lines
2.0 KiB
Markdown
26 lines
2.0 KiB
Markdown
|
||
|
||
## 事件存储计算模型
|
||
|
||
事件存储的数量是由摄像头办理的套餐决定的，目前摄像头大部分是使用事件存储套餐办理业务的，主要是资费便宜，但有些场景其实已经超出事件存储的要求，所以造成部分用户对事件存储的要求比较高，不丢文件是最基本的要求。
|
||
|
||
事件存储是由摄像头的移动监测告警触发，需要进行存储的请求。现在业务的要求是，触发时，保存触发时前30秒和后30秒的内容作为视频文件保存。所以实时性要求也很高。因为有前30秒的需求，所以系统中有事件服务，他的主要工作就是把直播内容在内存中缓存30秒，以被触发时的要求。当被触发时，视频码流会被写入磁盘，原则上是应该被同步写入云盘的，但目前由于云存不稳定，所以采用异步的模式进行写入。异步模型下，我们设置了10个线程来进行异步的本地和NFS之间的数据同步。
|
||
|
||
目前264的码流，理论上1分钟会生成2/8*60=15M的文件，实际上我们的文件大小基本在11M以下。但265的码流情况现在不详。
|
||
|
||
|
||
```
|
||
事件的触发量是个动态数据，根据我们曲线的观察，基本上在事件负载的0.3-0.5之间变动。
|
||
由于NFS不具备负载均衡模型，所以要事件服务来做存储的负载均衡模型，所以每个单点的NFS，从负载均衡及HA情况下，我认为3台是个基本要求。
|
||
事件服务的负载能力单台我们根据目前的负载来看，400是个比较有性价比的数据，系统稳定性和网络压力、业务分摊等等会相对合理。
|
||
|
||
依据以上的模型，对未来存储网关提出的最低要求：
|
||
400（单台事件负载）*0.5（触发比例）*11（每分钟码流）/ 60 （换算成秒）* 3（3台事件用一个网关）= 110M/S
|
||
|
||
如果将来的网关具备负载均衡的能力，需要重新计算模型。
|
||
|
||
网关数量：
|
||
5000（事件总负载） / 400（单台负载配置）/ 3 （至少3个1组）= 5
|
||
```
|
||
|