我的三六九原则
模式和框架应该简单,一旦有复杂化的迹象就需要做抽象和分解,核心要点限制在 3 点, 核心步骤限制在 6 步, 核心方法限制在 9 个.
Category: Uncategorized
模式和框架应该简单,一旦有复杂化的迹象就需要做抽象和分解,核心要点限制在 3 点, 核心步骤限制在 6 步, 核心方法限制在 9 个.
Every asynchronous agent has an associated executor. An agent’s executor determines how the agent’s completion handlers are queued and ultimately run. 每个异步代理都有一个关联的执行器。 代理的执行者确定代理的完成处理程序如何排队并最终运行 Example uses of executors include: Coordinating a group of asynchronous agents that operate on shared data structures, ensuring that the agents’ completion handlers never run concurrently[5]. Ensuring that agents are run on […]
@startuml struct AlrDetectorConfig { double bandwidth_usage_ratio = 0.65; double start_budget_level_ratio = 0.80; double stop_budget_level_ratio = 0.50; std::unique_ptr<StructParametersParser> Parser(); } class AlrDetector { void OnBytesSent(size_t bytes_sent, int64_t send_time_ms); void SetEstimatedBitrate(int bitrate_bps); absl::optional<int64_t> GetApplicationLimitedRegionStartTime() const; const AlrDetectorConfig conf_; absl::optional<int64_t> last_send_time_ms_; IntervalBudget alr_budget_; absl::optional<int64_t> alr_started_time_ms_; RtcEventLog* event_log_; } AlrDetectorConfig –o AlrDetector @enduml
Overview 每个流都有一个配置 struct StreamConfig { StreamConfig(); StreamConfig(const StreamConfig& other); ~StreamConfig(); bool operator==(const StreamConfig& other) const; bool operator!=(const StreamConfig& other) const; uint32_t local_ssrc = 0; uint32_t remote_ssrc = 0; uint32_t rtx_ssrc = 0; std::string rsid; bool remb = false; std::vector<RtpExtension> rtp_extensions; RtcpMode rtcp_mode = RtcpMode::kReducedSize; struct Codec { Codec(absl::string_view payload_name, int payload_type, int rtx_payload_type); bool operator==(const […]
USE Utilization 利用率 Saturation 饱和度 Error 错误率 RED Rate 每秒接收的请求数 Error 每秒失败的请求数 Duration 每个请求的耗时 Gold metrics Latency 处理请求所需的时间 Traffic 处理请求所需的流量 Error 请求的错误率 Saturation 服务的资源使用情况
订阅一份报纸，到时候就会投递给你。 订阅一个新闻频道，一有新闻就会推送给你。 本质上，它是一种异步通信的架构模式 与之对应的代码模式就是观察者模式，其注册 register 对应于 subscribe, notify 对应于 publishe subscribe subscriber -> router: subscribe router–>subscriber: ack publisher publisher -> router: event router–>publisher: ack router –> subscriber: event subscviber–>router: ack 典型用例有 Ingestion user interaction and server events. To use user interaction events from end-user apps or server events from your system, you might forward them […]
这个世界再烂，也拒绝摆烂，写书，写代码，写评论，我写故我在。 与朋友去交流，跑步，打球，让自己流汗，不让自己流泪。
在 WebRTC 中常用的 QoS 策略有 反馈：例如 PLI , NACK 冗余， 例如 FEC, RTX 调整：例如码率，分辨率及帧率的调整 缓存: 例如 Receive Adaptive Jitter Buffer, Send Buffer 这些措施的采用需要基于拥塞控制(congestion control) 及带宽估计(bandwidth estimation)技术, 不同的网络条件下需要采用不同的措施。 Webrtc 默认是开启 RTX (重传)，它一般采用不同的 SSRC 进行传输 RTX 包的 Payload 在 RFC4588 中有详细描述，一般 NACK 和 Bandwidth Probe 也可能走 RTX 通道。 FEC 用作丢包恢复需要占用更多的带宽，即使 5% 的丢包需要几乎一倍的带宽，在带宽有限的情况下可能会使情况更糟。 RTX 不会占用太多的带宽，接收方发送 NACK 指明哪些包丢失了，发送方通过单独的 RTP […]
1) 是否容易重现 如果容易，它的复现步骤是什么 如果不容易，它在什么条件下的出现机率比较大，有没有可能缩小排查的范围 2) 是否最近才引入的，发现的时机和频率如何 找出 crash 出现的时间范围，时机，和频率 根据 backgrace 和 git log, 回顾 crash 相关代码的修改记录 3) 灵活运用演绎法，归纳法和二分法 演绎法: 从一般到特殊，从常见的 crash 问题和解决方案推断 归纳法: 从特殊到一般，从最近频发的 crash 问题找出共性特征 二分法: 用二分法合理划分问题域，不断缩小范围 4) 大胆假设，小心求证 假设条件，测试，排除，不断重复，缩小范围 有必要时画一张思维导图，记下每条排查路径 5) 君子性非异也，善假于物也 查询 google, stackflow, 听取同事的意见 最后一条，看看破案和推理小说及剧情，学学侦破技术 如何找线索， 如何勘查现场， 如何排查嫌疑 如何查询积案，进行并案 有一些惯犯和惯用作案手段值得研究 多线程处理不当 多个线程操作一块内存区域，没有安全地加锁和串行化 合局和单例对象是重点排查对象 内存处理不当 内存管理不当，用到的内存却给别人破坏了，例如 试图释放已经释放了的内存 试图释放并未分配的内存 试图读写已经释放了的内存 试图读写并未分配的内存 内存分配错误, […]
脚手架工具 生成模板代码，例如 yeoman 依赖管理工具 管理依赖代码，例如 bower 构建工具 预处理代码，例如 gulp