{"id":479420,"date":"2023-08-09T10:39:54","date_gmt":"2023-08-09T10:39:54","guid":{"rendered":""},"modified":"2023-09-05T11:18:47","modified_gmt":"2023-09-05T11:18:47","slug":"two-phase-commit","status":"publish","type":"wiki","link":"https:\/\/oneproxy.pro\/pt\/wiki\/two-phase-commit\/","title":{"rendered":"Confirma\u00e7\u00e3o em duas fases"},"content":{"rendered":"

Two-phase commit (2PC) \u00e9 um algoritmo distribu\u00eddo usado em ci\u00eancia da computa\u00e7\u00e3o para garantir a consist\u00eancia de uma transa\u00e7\u00e3o em v\u00e1rios bancos de dados ou recursos. Garante que todos os n\u00f3s participantes se comprometam com a transa\u00e7\u00e3o ou nenhum deles o fa\u00e7a, mantendo assim a integridade dos dados e evitando inconsist\u00eancias em sistemas distribu\u00eddos.<\/p>\n

A hist\u00f3ria da origem do commit em duas fases e a primeira men\u00e7\u00e3o dele<\/h2>\n

O conceito de commit em duas fases foi introduzido pela primeira vez por EW Dijkstra em 1974 em seu artigo intitulado \u201cSolu\u00e7\u00e3o de um problema no controle de programa\u00e7\u00e3o simult\u00e2nea\u201d. Mais tarde, em 1981, o protocolo de commit de duas fases foi formalmente descrito por Jim Gray e Andreas Reuter em seu influente artigo \u201cTransaction Processing: Concepts and Techniques\u201d.<\/p>\n

Informa\u00e7\u00f5es detalhadas sobre commit em duas fases<\/h2>\n

A confirma\u00e7\u00e3o em duas fases foi projetada para gerenciar transa\u00e7\u00f5es distribu\u00eddas onde v\u00e1rios n\u00f3s ou bancos de dados est\u00e3o envolvidos. \u00c9 essencial garantir que todos os n\u00f3s concordem em confirmar ou abortar a transa\u00e7\u00e3o. O protocolo opera em duas fases: a fase de prepara\u00e7\u00e3o e a fase de confirma\u00e7\u00e3o.<\/p>\n

Na fase de prepara\u00e7\u00e3o:<\/p>\n

    \n
  1. O n\u00f3 coordenador envia uma solicita\u00e7\u00e3o de prepara\u00e7\u00e3o a todos os n\u00f3s participantes.<\/li>\n
  2. Cada participante responde concordando (SIM) ou discordando (N\u00c3O).<\/li>\n
  3. Caso algum participante discorde, o coordenador instrui todos os n\u00f3s a abortar a transa\u00e7\u00e3o.<\/li>\n<\/ol>\n

    Na fase de confirma\u00e7\u00e3o:<\/p>\n

      \n
    1. Se todos os participantes concordarem (SIM) durante a fase de prepara\u00e7\u00e3o, o coordenador envia uma solicita\u00e7\u00e3o de commit a todos os n\u00f3s.<\/li>\n
    2. Ao receber a solicita\u00e7\u00e3o de commit, cada participante finaliza a transa\u00e7\u00e3o tornando permanentes as altera\u00e7\u00f5es necess\u00e1rias.<\/li>\n
    3. Caso algum participante discorde (N\u00c3O) durante a fase de prepara\u00e7\u00e3o, o coordenador envia uma solicita\u00e7\u00e3o de aborto a todos os n\u00f3s e a transa\u00e7\u00e3o \u00e9 revertida.<\/li>\n<\/ol>\n

      A estrutura interna do commit em duas fases e como funciona<\/h2>\n

      A confirma\u00e7\u00e3o de duas fases envolve os seguintes componentes:<\/p>\n

        \n
      1. \n

        Coordenador<\/strong>: Respons\u00e1vel por iniciar e gerenciar a transa\u00e7\u00e3o. Ele se comunica com todos os n\u00f3s participantes e determina se deve confirmar ou abortar a transa\u00e7\u00e3o com base em suas respostas.<\/p>\n<\/li>\n

      2. \n

        Participantes<\/strong>: N\u00f3s ou bancos de dados envolvidos na transa\u00e7\u00e3o. Eles respondem \u00e0 solicita\u00e7\u00e3o de prepara\u00e7\u00e3o do coordenador com acordo ou desacordo.<\/p>\n<\/li>\n

      3. \n

        Log de transa\u00e7\u00f5es<\/strong>: Cada participante mant\u00e9m um log de transa\u00e7\u00f5es, que registra todas as altera\u00e7\u00f5es feitas durante a transa\u00e7\u00e3o. Esse log ajuda a garantir que as altera\u00e7\u00f5es possam ser revertidas, se necess\u00e1rio.<\/p>\n<\/li>\n<\/ol>\n

        O algoritmo prossegui como desejado:<\/p>\n

          \n
        1. \n

          O coordenador inicia a fase de prepara\u00e7\u00e3o enviando uma solicita\u00e7\u00e3o de prepara\u00e7\u00e3o a todos os participantes.<\/p>\n<\/li>\n

        2. \n

          Cada participante vota (concorda ou discorda) se pode realizar a transa\u00e7\u00e3o.<\/p>\n<\/li>\n

        3. \n

          O coordenador coleta todos os votos e decide se compromete ou aborta a transa\u00e7\u00e3o.<\/p>\n<\/li>\n

        4. \n

          Na fase de confirma\u00e7\u00e3o, o coordenador envia uma solicita\u00e7\u00e3o de confirma\u00e7\u00e3o ou de cancelamento a todos os participantes com base no resultado da fase de prepara\u00e7\u00e3o.<\/p>\n<\/li>\n

        5. \n

          Os participantes executam a decis\u00e3o final, seja comprometendo as altera\u00e7\u00f5es permanentemente ou revertendo a transa\u00e7\u00e3o.<\/p>\n<\/li>\n<\/ol>\n

          An\u00e1lise dos principais recursos do commit em duas fases<\/h2>\n

          O commit em duas fases oferece v\u00e1rios recursos principais:<\/p>\n

            \n
          1. \n

            Atomicidade<\/strong>: garante que todos os n\u00f3s sejam confirmados ou nenhum deles o fa\u00e7a, evitando atualiza\u00e7\u00f5es parciais ou inconsistentes.<\/p>\n<\/li>\n

          2. \n

            Consist\u00eancia<\/strong>: O protocolo garante que o sistema permane\u00e7a consistente, mesmo na presen\u00e7a de falhas.<\/p>\n<\/li>\n

          3. \n

            Durabilidade<\/strong>: depois que a transa\u00e7\u00e3o \u00e9 confirmada, as altera\u00e7\u00f5es se tornam permanentes e sobrevivem \u00e0s falhas do sistema.<\/p>\n<\/li>\n

          4. \n

            Bloqueando a Natureza<\/strong>: A confirma\u00e7\u00e3o em duas fases tem uma natureza de bloqueio, o que significa que pode esperar indefinidamente por uma resposta dos participantes, levando a poss\u00edveis atrasos.<\/p>\n<\/li>\n<\/ol>\n

            Tipos de commit em duas fases<\/h2>\n

            Existem varia\u00e7\u00f5es do protocolo de confirma\u00e7\u00e3o de duas fases, incluindo:<\/p>\n\n\n\n\n\n\n\n
            Tipo<\/th>\nDescri\u00e7\u00e3o<\/th>\n<\/tr>\n<\/thead>\n
            Confirma\u00e7\u00e3o b\u00e1sica de duas fases<\/td>\nA vers\u00e3o padr\u00e3o descrita anteriormente.<\/td>\n<\/tr>\n
            Confirma\u00e7\u00e3o trif\u00e1sica<\/td>\nAdiciona uma fase extra de \u201cpr\u00e9-comprometimento\u201d para resolver problemas de bloqueio.<\/td>\n<\/tr>\n
            Compromisso otimista<\/td>\nPermite que os participantes se comprometam previamente antes de receber a decis\u00e3o do coordenador.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

            Maneiras de usar o commit em duas fases, problemas e suas solu\u00e7\u00f5es<\/h2>\n

            O commit em duas fases encontra aplica\u00e7\u00f5es em v\u00e1rios campos, como:<\/p>\n

              \n
            1. \n

              Gerenciamento de banco de dados<\/strong>: Garantindo consist\u00eancia e integridade em sistemas de banco de dados distribu\u00eddos.<\/p>\n<\/li>\n

            2. \n

              Transa\u00e7\u00f5es de com\u00e9rcio eletr\u00f4nico<\/strong>: Gerenciando transa\u00e7\u00f5es em v\u00e1rios servidores durante compras online.<\/p>\n<\/li>\n<\/ol>\n

              No entanto, o protocolo tem algumas limita\u00e7\u00f5es:<\/p>\n

                \n
              1. \n

                Bloqueio<\/strong>: A natureza de bloqueio do 2PC pode levar a problemas de desempenho, especialmente em sistemas de grande escala.<\/p>\n<\/li>\n

              2. \n

                Ponto unico de falha<\/strong>: O coordenador atua como ponto \u00fanico de falha; se travar, todo o processo de transa\u00e7\u00e3o poder\u00e1 falhar.<\/p>\n<\/li>\n<\/ol>\n

                Para mitigar esses problemas, algumas solu\u00e7\u00f5es incluem:<\/p>\n

                  \n
                1. \n

                  Otimiza\u00e7\u00f5es<\/strong>: implementa\u00e7\u00e3o de t\u00e9cnicas de otimiza\u00e7\u00e3o, como estrat\u00e9gias de commit antecipado ou de commit sem bloqueio, para reduzir problemas de bloqueio.<\/p>\n<\/li>\n

                2. \n

                  Redund\u00e2ncia de Coordenador<\/strong>: Apresentando redund\u00e2ncia de coordenador com um mecanismo de failover para melhorar a toler\u00e2ncia a falhas.<\/p>\n<\/li>\n<\/ol>\n

                  Principais caracter\u00edsticas e outras compara\u00e7\u00f5es com termos semelhantes<\/h2>\n\n\n\n\n\n\n\n\n
                  Caracter\u00edstica<\/th>\nCompara\u00e7\u00e3o com commit em duas fases<\/th>\n<\/tr>\n<\/thead>\n
                  Consist\u00eancia<\/td>\nSemelhante ao commit trif\u00e1sico e ao Paxos na manuten\u00e7\u00e3o da consist\u00eancia em sistemas distribu\u00eddos.<\/td>\n<\/tr>\n
                  Desempenho<\/td>\nComparado ao Paxos e ao Raft, o commit em duas fases pode apresentar maior lat\u00eancia devido ao bloqueio.<\/td>\n<\/tr>\n
                  Toler\u00e2ncia ao erro<\/td>\nO commit em duas fases e o Paxos fornecem toler\u00e2ncia a falhas, enquanto o commit em duas fases \u00e9 mais simples de implementar.<\/td>\n<\/tr>\n
                  Despesas gerais de comunica\u00e7\u00e3o<\/td>\nO Raft tem menor sobrecarga de comunica\u00e7\u00e3o do que o Two-phase commit, tornando-o mais adequado para sistemas de grande escala.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

                  Perspectivas e tecnologias do futuro relacionadas ao compromisso em duas fases<\/h2>\n

                  \u00c0 medida que os sistemas distribu\u00eddos continuam a evoluir, poder\u00e3o surgir protocolos de transa\u00e7\u00e3o mais eficientes e tolerantes a falhas. Os pesquisadores est\u00e3o explorando alternativas como Raft, Paxos e variantes do Two-phase commit para resolver as limita\u00e7\u00f5es e problemas de escalabilidade. Al\u00e9m disso, os avan\u00e7os nos algoritmos de consenso e no aprendizado de m\u00e1quina podem levar a novas maneiras de alcan\u00e7ar um acordo distribu\u00eddo.<\/p>\n

                  Como os servidores proxy podem ser usados ou associados ao commit de duas fases<\/h2>\n

                  Os servidores proxy atuam como intermedi\u00e1rios entre clientes e servidores, lidando com solicita\u00e7\u00f5es e respostas em nome dos clientes. Embora n\u00e3o estejam diretamente associados ao Two-phase commit, os servidores proxy podem desempenhar um papel significativo na distribui\u00e7\u00e3o de transa\u00e7\u00f5es entre v\u00e1rios servidores back-end.<\/p>\n

                  Quando os clientes iniciam transa\u00e7\u00f5es distribu\u00eddas por meio de um servidor proxy, o proxy pode rotear solicita\u00e7\u00f5es de forma inteligente para diferentes n\u00f3s de back-end, participando do protocolo Two-phase commit. Isso permite balanceamento de carga e maior toler\u00e2ncia a falhas em sistemas distribu\u00eddos. Al\u00e9m disso, os servidores proxy podem armazenar respostas em cache, reduzindo a carga nos n\u00f3s de back-end e melhorando o desempenho geral do sistema.<\/p>\n

                  Links Relacionados<\/h2>\n