Design on Rickyhttps://linzeyan.github.io/zh-tw/categories/design/Recent content in Design on RickyHugo -- gohugo.iozh-twTue, 18 Apr 2023 13:58:38 +0800一些软件设计的原则https://linzeyan.github.io/zh-tw/posts/2023/20230418-software-design-principles/Tue, 18 Apr 2023 13:58:38 +0800https://linzeyan.github.io/zh-tw/posts/2023/20230418-software-design-principles/<ul> <li><a href="https://coolshell.cn/articles/4535.html" target="_blank" rel="noopener">一些软件设计的原则</a></li> </ul> <h3 id="1-dont-repeat-yourself-dry">1. Don&rsquo;t Repeat Yourself (DRY)</h3> <h3 id="2-keep-it-simple-stupid-kiss">2. Keep It Simple, Stupid (KISS)</h3> <p>把一个事情搞复杂是一件简单的事，但要把一个复杂的事变简单，这是一件复杂的事。</p> <h3 id="3-program-to-an-interface-not-an-implementation">3. Program to an interface, not an implementation</h3> <ol> <li>喜欢组合而不是继承</li> <li>依赖倒置原则</li> </ol> <h3 id="4-command-query-separation-cqs---命令-查询分离原则">4. Command-Query Separation (CQS) - 命令-查询分离原则</h3> <ul> <li>查询：当一个方法返回一个值来回应一个问题的时候，它就具有查询的性质；</li> <li>命令：当一个方法要改变对象的状态的时候，它就具有命令的性质；</li> </ul> <h3 id="5-you-aint-gonna-need-it-yagni">5. You Ain&rsquo;t Gonna Need It (YAGNI)</h3> <p>只考虑和设计必须的功能，避免过度设计。只实现目前需要的功能，在以后您需要更多功能时，可以再进行添加。</p> <h3 id="6-law-of-demeter---迪米特法则">6. Law of Demeter - 迪米特法则</h3> <blockquote> <p>最少知识原则（Principle of Least Knowledge） 不要和陌生人说话</p></blockquote> <blockquote> <p>如果你想让你的狗跑的话，你会对狗狗说还是对四条狗腿说？ 如果你去店里买东西，你会把钱交给店员，还是会把钱包交给店员让他自己拿？</p></blockquote> <p>对于对象 O 中一个方法 M ，M 应该只能够访问以下对象中的方法：</p> <ol> <li>对象 O；</li> <li>与 O 直接相关的 Component Object；</li> <li>由方法 M 创建或者实例化的对象；</li> <li>作为方法 M 的参数的对象。</li> </ol> <h3 id="7-面向对象的-solid-原则">7. 面向对象的 S.O.L.I.D 原则</h3> <h4 id="single-responsibility-principle-srp---职责单一原则">Single Responsibility Principle (SRP) - 职责单一原则</h4> <p>一个类，只做一件事，并把这件事做好，其只有一个引起它变化的原因</p>关于高可用的系统https://linzeyan.github.io/zh-tw/posts/2023/20230418-high-availability-system/Tue, 18 Apr 2023 10:24:00 +0800https://linzeyan.github.io/zh-tw/posts/2023/20230418-high-availability-system/<ul> <li><a href="https://coolshell.cn/articles/17459.html" target="_blank" rel="noopener">关于高可用的系统</a></li> </ul> <table> <thead> <tr> <th>項目 / 機制</th> <th>Backups</th> <th>M/S</th> <th>MM</th> <th>2PC</th> <th>Paxos</th> </tr> </thead> <tbody> <tr> <td>Consistency</td> <td>Weak</td> <td>Eventual</td> <td>Eventual</td> <td>Strong</td> <td>Strong</td> </tr> <tr> <td>Transactions</td> <td>No</td> <td>Full</td> <td>Local</td> <td>Full</td> <td>Full</td> </tr> <tr> <td>Latency</td> <td>Low</td> <td>Low</td> <td>Low</td> <td>High</td> <td>High</td> </tr> <tr> <td>Throughput</td> <td>High</td> <td>High</td> <td>High</td> <td>Low</td> <td>Medium</td> </tr> <tr> <td>Data loss</td> <td>Lots</td> <td>Some</td> <td>Some</td> <td>None</td> <td>None</td> </tr> <tr> <td>Failover</td> <td>Down</td> <td>Read only</td> <td>Read only</td> <td>Read/write</td> <td>Read/write</td> </tr> </tbody> </table> <p>这个图基本上来说是目前高可用系统中能看得到的所有的解决方案的基础了。M/S、MM 实现起来不难，但是会有很多问题，2PC 的问题就是性能不行，而 Paxos 的问题就是太复杂，实现难度太大。</p> <p>总结一下各个高可用方案的的问题：</p> <ul> <li>对于最终一致性来说，在宕机的情况下，会出现数据没有完全同步完成，会出现数据差异性。</li> <li>对于强一致性来说，要么使用性能比较慢的 XA 系的两阶段提交的方案，要么使用性能比较好，但是实现比较复杂的 Paxos 协议。</li> </ul>