Os guias a seguir são todas as pessoas que pisaram ou aprenderam sobre os buracos que os colegas ao meu redor realmente pisaram. Espero fornecer um pouco de esclarecimento e ajuda para aqueles que estão prestes a entrar no pagamento financeiro e de comércio eletrônico e outros setores relacionados, e para aqueles que acabaram de entrar no setor alfandegário. !
1. O sistema financeiro usa bigdecimal para processar o valor e especifica a casa decimal
Para quem tem experiência na área financeira, você saberá que ao lidar com valores procure não usar double ou float porque a precisão se perderá, o que pode causar erros de cálculo. Você deve usar bigdecimal, mas isso ainda não o impede de pisar no buraco, porque você também está yang muito simples!
Na verdade, o uso indevido de bigdecimal é ainda a perda de precisão (não dê um exemplo de busca online, muito!), Aqui eu quero te dizer como lidar com isso: " designar casas decimais "!, Espero que você não pise nisso de novo!
2. Confirme a unidade de quantidade repetidamente para o campo de quantidade da interface
Sempre tem algumas pessoas que não gostam de usar seus cérebros, haha, depois de obter a interface (como a interface de pagamento), eles nem pensam sobre isso, então passam o valor para o campo de valor da interface. Eles não sabem que estão pedindo para passar o yuan, você deu. São pontos! ! ! Você colocou 500 pontos na interface e as três partes pagaram 500 yuan. O usuário pensou (tão feliz ...)
Por isso aviso que ao ver uma interface com um valor, você deve confirmar a unidade do valor (incluindo o valor devolvido)!
3. Para o status da interface de transação, é necessário confirmar repetidamente o status da transação de qual código de campo
Por exemplo, a seguinte mensagem de retorno de interface de três partes
{ "sucesso": verdadeiro, "resultado": { "status": "0", "amt": "100,00" ..... } }
status = 0 significa fracasso comercial
Se a pessoa que conecta a interface não confirmar sob quais circunstâncias o serviço de código foi bem-sucedido, ela considerará sucesso = verdadeiro como sucesso e retornará a mensagem acima como uma falha de serviço, que pode eventualmente levar à perda de capital.
O retorno acima, após confirmação com o provedor de interface, o campo de sucesso representa apenas o status de comunicação deste pedido, não o status do negócio. Se este pedido for um pedido de dedução para compra de produto, pense nisso, o dinheiro não foi deduzido Para o usuário, o produto pode ter sido enviado! ! !
4. Para a interface que retornará o valor da transação, certifique-se de confirmar se a transação será parcialmente bem-sucedida
Em alguns cenários de negócios, haverá casos em que o valor do aplicativo é inconsistente com o valor confirmado (pode ser parcialmente bem-sucedido). Neste momento, se chamarmos a interface de três (duas) partes, não prestamos atenção ao valor retornado pela interface e usamos diretamente a interface para tornar o status da transação bem-sucedido Para determinar o processamento subsequente, é fácil causar perda de capital.
Se for confirmado que a interface da transação não será parcialmente bem-sucedida, mas a interface retorna o campo de valor, podemos verificar o valor do aplicativo novamente após a lógica de negócios confirmar que o status do negócio é bem-sucedido e se é consistente com o valor confirmado para garantir que a transação seja totalmente bem-sucedida!
5. A interface da transação deve ser idempotente!
Isto é muito, muito importante! ! ! , Se você não sabe o que é idempotência, vá para o Baidu (sem Google)! Pense nisso se uma transação não for idempotente, se for um pagamento (retirada) em um cenário concorrente, ela se chama N vezes, e o resultado é pago ao usuário N vezes, o usuário pensa (que bom ...)
No futuro, quer você ajuste a API de outras pessoas ou queira fornecer a API a outras pessoas, lembre-se de garantir que a interface seja idempotente, para que "olá, é bom". . .
6. A interface de retorno de chamada assíncrona deve ser idempotente!
Isso também é muito importante! ! ! , Nunca acredite que "uma transação será devolvida apenas uma vez ou uma transação com falha não será devolvida". Porque haverá várias solicitações de retorno de chamada para uma transação!
1). Idempotente para fazer 2). Se o chamador disser que a falha não retornará a chamada, devemos adicionar a lógica do retorno de chamada com falha 3). Se o chamador disser que o sucesso não retornará a chamada, devemos adicionar a lógica do retorno de chamada com sucesso
7. Mecanismo de compensação para pedidos anormais (pedidos de reposição de consulta)
Durante a chamada da interface, é normal que ocorram problemas como exceções e tempos limite de chamadas. Em alguns cenários, podemos fazer algum processamento de compensação, como consulta e reposição de pedidos.
Consultar o pedido de reposição significa que ocorre uma anormalidade no pedido durante a transação e um estado intermediário com resultados de transação desconhecidos é produzido. Nesse momento, você pode usar a interface de consulta fornecida pelas três partes (duas partes) para reconfirmar o resultado do pedido original e fazer algo com base no resultado. Operações de compensação, como pedidos de reposição. Um ponto importante aqui é confirmar se a interface de consulta de três partes tem um limite de tempo de consulta . Algumas interfaces de três partes não podem ser consultadas imediatamente após a transação. Pode ser necessário esperar alguns minutos antes da operação (pode ser um problema de sincronização). Consultar com antecedência, a interface retorna uma resposta de que o pedido não existe, resultando em erros no processamento subsequente!
8. É proibido solicitar interfaces tripartidas e bilaterais ou aninhar lógicas complexas e demoradas em interfaces com transações
Às vezes, a atualização e outras operações no método de transação precisam solicitar as três partes antes de usar os resultados retornados pelas três partes para fazer a atualização. Isso acontecerá. Se o desempenho da interface de três partes for problemático, a transação inteira não poderá ser enviada por um longo tempo e a conexão com o banco de dados não será liberada. Quando a quantidade de solicitações é grande, os ativos do banco de dados não são suficientes, o que pode causar o tempo de inatividade do sistema.
9. Atualizando continuamente. . . .