Danny AJ

  What is Ansible? Ansible is an open-source IT tool provided by Red-Hat Enterprise Linux (RHEL) that helps in configuration management, orchestration service, task, and application deployment automation. This tool is aimed to help system administrators who are seeking to minimize recurring tasks, seamless deployment, and easy automation. Similar tools to Ansible are Puppet, SaltStack, and Chef, which are the main configuration management tools available on the market. Each one of these tools has its advantages and disadvantages, so choosing the right one can be a bit challenging, depending on which features are needed or which programming language is preferred. From the advantages of Ansible compared to other tools, Ansible is sort of a new tool that is built on Python and uses YAML templates for scripting its jobs. YAML stands for “YAML Ain’t Markup Language,” which is a very easy human-readable language. This helps new users to understand it easily. Another advantage is to use A...

  Why Ansible Vault?: Ansible had no mechanism in which users can encrypt data such as a Playbook and Role and if any third-party module for encryption was used, it caused many problems in terms of Encrypting the Data and Decrypting it at times of Execution, this lead to the idea of a Utility which can fix this gap and provide better functionality with Ansible. What is Ansible Vault? Vault is a mechanism that allows encrypted content to be incorporated transparently into Ansible workflows. A utility called ansible-vault secures confidential data by encrypting it on disk. To integrate these secrets with regular Ansible data, both the ansible and ansible-playbook commands. It uses the  AES256  algorithm to provide symmetric encryption keyed to a user-supplied password. This means that the same password is used to encrypt and decrypt content, which is helpful from a usability standpoint. Now that you understand a bit about what Vault is, we can start discussing the tools Ans...

主要內容    緩存熱點數據    為何要使用緩存    哪類數據適合緩存    緩存的利與弊    緩存和數據庫雙寫一致性    不使用更新緩存而是刪除緩存    先刪除緩存，還是先操作數據庫？    我一定要數據庫和緩存數據一致怎麼辦    實戰：先刪除緩存，再更新數據庫    實戰：先更新數據庫，再刪緩存    實戰：刪除緩存重試機制    實戰：刪除緩存重試機制    實戰：讀取binlog異步刪除緩存 緩存熱點數據    在秒殺實際的業務中，一定有很多需要做緩存的場景，比如售賣的商品，包括名稱，詳情等。訪問量很大的數據，可以算是“熱點”數據了，尤其是一些讀取量遠大於寫入量的數據，更應該被緩存，而不應該讓請求打到數據庫上。 哪類數據適合緩存    緩存量大但又不常變化的數據，比如詳情，評論等。對於那些經常變化的數據，其實並不適合緩存，一方面會增加系統的複雜性（緩存的更新，緩存臟數據），另一方面也給系統帶來一定的不穩定性（緩存系統的維護） 。 但一些極端情況下，你需要將一些會變動的數據進行緩存，比如想要頁面顯示準實時的庫存數，或者其他一些特殊業務場景。這時候你需要保證緩存不能（一直）有臟數據，這就需要再深入討論一下。 緩存的利與弊     我們到底該不該上緩存的，這其實也是個trade-off的問題。 上緩存的優點： 能夠縮短服務的響應時間，給用戶帶來更好的體驗。 能夠增大系統的吞吐量，依然能夠提升用戶體驗。 減輕數據庫的壓力，防止高峰期數據庫被壓垮，導致整個線上服務BOOM！ 上了緩存，也會引入很多額外的問題： 緩存有多種選型，是內存緩存，memcached還是redis，你是否都熟悉，如果不熟悉，無疑增加了維護的難度（本來是個純潔的數據庫系統）。 緩存系統也要考慮分佈式，比如redis的分佈式緩存還會有很多坑，無疑增加了系統的複雜性。 在特殊場景下，如果對緩存的準確性有非常高的...

停機遷移方案 我先給你說一個最low 的方案，就是很簡單，大傢伙兒凌晨12 點開始運維，網站或者app 掛個公告，說0 點到早上6 點進行運維，無法訪問。 接著到0點停機，系統停掉，沒有流量寫入了，此時老的單庫單表數據庫靜止了。 然後你之前得寫好一個 導數的一次性工具 ，此時直接跑起來，然後將單庫單表的數據嘩嘩嘩讀出來，寫到分庫分錶裡面去。 導數完了之後，就ok 了，修改系統的數據庫連接配置啥的，包括可能代碼和SQL 也許有修改，那你就用最新的代碼，然後直接啟動連到新的分庫分錶上去。 驗證一下，ok了，完美，大家伸個懶腰，看看看凌晨4 點鐘的北京夜景，打個滴滴回家吧。 但是這個方案比較low，誰都能幹，我們來看看高大上一點的方案。 雙寫遷移方案 這個是我們常用的一種遷移方案，比較靠譜一些，不用停機，不用看北京凌晨4 點的風景。 簡單來說，就是在線上系統裡面，之前所有寫庫的地方，增刪改操作， 除了對老庫增刪改，都加上對新庫的增刪改 ，這就是所謂的 雙寫 ，同時寫倆庫，老庫和新庫。 然後 系統部署 之後，新庫數據差太遠，用之前說的導數工具，跑起來讀老庫數據寫新庫，寫的時候要根據gmt_modified這類字段判斷這條數據最後修改的時間，除非是讀出來的數據在新庫裡沒有，或者是比新庫的數據新才會寫。 簡單來說，就是不允許用老數據覆蓋新數據。 導完一輪之後，有可能數據還是存在不一致，那麼就程序自動做一輪校驗，比對新老庫每個表的每條數據，接著如果有不一樣的，就針對那些不一樣的，從老庫讀數據再次寫。 反复循環，直到兩個庫每個表的數據都完全一致為止。 接著當數據完全一致了，就ok 了，基於僅僅使用分庫分錶的最新代碼，重新部署一次，不就僅僅基於分庫分錶在操作了麼，還沒有幾個小時的停機時間，很穩。 所以現在基本玩兒數據遷移之類的，都是這麼幹的。

ShardingSphere是一套开源的分布式数据库中间件解决方案组成的生态圈，它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar（计划中）这3款相互独立的产品组成。 他们均提供标准化的数据分片、分布式事务和数据库治理功能，可适用于如Java同构、异构语言、云原生等各种多样化的应用场景。 ShardingSphere定位为关系型数据库中间件，旨在充分合理地在分布式的场景下利用关系型数据库的计算和存储能力，而并非实现一个全新的关系型数据库。 它与NoSQL和NewSQL是并存而非互斥的关系。NoSQL和NewSQL作为新技术探索的前沿，放眼未来，拥抱变化，是非常值得推荐的。反之，也可以用另一种思路看待问题，放眼未来，关注不变的东西，进而抓住事物本质。 关系型数据库当今依然占有巨大市场，是各个公司核心业务的基石，未来也难于撼动，我们目前阶段更加关注在原有基础上的增量，而非颠覆。 ShardingSphere目前已经进入 Apache孵化器 ， 欢迎通过 shardingsphere的dev邮件列表 与我们讨论。             简介 Sharding-JDBC 定位为轻量级Java框架，在Java的JDBC层提供的额外服务。 它使用客户端直连数据库，以jar包形式提供服务，无需额外部署和依赖，可理解为增强版的JDBC驱动，完全兼容JDBC和各种ORM框架。 适用于任何基于JDBC的ORM框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template或直接使用JDBC。 支持任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, Druid, HikariCP等。 支持任意实现JDBC规范的数据库。目前支持MySQL，Oracle，SQLServer，PostgreSQL以及任何遵循SQL92标准的数据库。 Sharding-Proxy   定位为透明化的数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支持。 目前先提供MySQL/PostgreSQL版本，它可以使用任何兼容MySQL/PostgreSQL协议...