Shulou(Shulou.com)06/01 Report--

Big data in how to solve the snowflake algorithm ID to the front end after the loss of accuracy, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain in detail for you, people with this need can come to learn, I hope you can gain something.

Recently, a project team of the company wants to split the previous single application into services, and the ID primary key of the table is generated using Mybatis plus's default snowflake algorithm.

When I was about to get off work, my partner ran to me and said, "show me this problem. It's been stuck for a long time!" . Pull and pull, coax and deceive me in front of his computer. This little friend is not a big cow in my opinion, but he has a lot of experience. He had been stuck for a long time, which should not be a small problem. If I couldn't handle it at 01:30, it would really delay my getting off work, so I sat down in his seat reluctantly.

First, the phenomenon is like this

Next, I would like to describe the abnormal phenomenon to you. My partner built a table. The primary key of the table is id BigINT, which is used to store the ID generated by Snowflake algorithm. Well, this is no problem!

CREATE TABLE user (id BIGINT (20) NOT NULL COMMENT 'primary key ID', # other fields omitted)

Use the Long type to correspond to database ID data. Well, there's no problem. Snowflake algorithm generates a string of numbers, and the Long type belongs to the standard answer!

[@ Data] (https://my.oschina.net/difrik)public class User {private Long id;// other member variables omitted

The breakpoint at the back end. See the data response to the front end with JSON response, normal

{id:1297873308628307970,// other properties are omitted}

Finally, the data is returned to the front end, and after it is received by the front end, the data is modified and the back end receives it again. A strange problem arises: the id re-received by the backend becomes: 12978733086283000000, no longer 129787330828307970

Second, analyze the problem

My first feeling is that the developer partner got the data mixed up, got the wrong object, and put the XXX object ID on the ID of the YYY object. So, follow the code from front-end to back-end, from back-end to front-end debugging and trace.

There is no problem from the logic of the code. At this time, I was a little irritable, really delayed my work! But he didn't look back at work, and since he sat down, he had to help him solve it, otherwise how could this team take it in the future? When I thought of this, I calmed down and began to think.

1297873308628300000-> 1297873308628307970

The two numbers look alike and seem to have been rounded. At this time, an idea came into my head, is the precision lost? Where can lead to loss of accuracy?

The server is all id of Long type, so it is impossible to lose it.

What is the type of the front end? the JSON string converts the js object, and the one that receives the Long type is number.

Surf the Internet to check the accuracy loss caused by the Number accuracy of 16 bits (Snow ID is 19 bits) and the Number data type of So:JS. The problem is that I found it! The little friend cast a look of admiration and discovered the problem in 5 minutes. But what's the use of finding it? We have to solve the problem!

Third, solve the problem

The developer said: then I will design all the database tables and change the id field from Long type to String type. I asked him how many tables you had. He said more than 100.

More than 100 tables and more than 100 entity classes need to be changed.

There are also various Service layers that use entity classes to change.

Service and so on, the Controller layer needs to be changed.

The key point is that both String and Long are commonly used types, and he doesn't dare to replace them in batches.

My friend picked up the phone and prepared to order food, saying that overtime work tonight was inevitable. I thought about it and said: you'd better not change, String do ID query performance will decline, I think again! The precision of the back end A to the front end B is lost, either change the front end, or change the back end, or …... No, no, no. "Hey, wait a minute, don't order a meal. What do you use to serialize from back-end A to front-end B?" My partner told me that I used Jackson, which is easy to do. I am familiar with Jackson.

Solution: the backend ID (Long) = > Jackson (Long to String) = = > the front end uses String type ID, so the precision of the front end using js string will not be lost. When the front end sends 19 digits of the String type back to the server, can it be received by Long? Of course, this is the behavior supported by default for Spring deserialization parameter reception.

The final solution is: the front end uses String type snowflake ID to maintain accuracy, and the back end and database continue to use Long (BigINT) type does not affect the efficiency of database query execution.

The remaining question is: in Spring Boot applications, how to convert the Long type ID to the String response to the front end when using Jackson for JSON serialization. The plan is as follows:

[@ Configuration] (https://my.oschina.net/pointdance)public class JacksonConfig {[@ Bean] (https://my.oschina.net/bean) [@ Primary] (https://my.oschina.net/primary) @ ConditionalOnMissingBean (ObjectMapper.class) public ObjectMapper jacksonObjectMapper (Jackson2ObjectMapperBuilder builder) {ObjectMapper objectMapper = builder.createXmlMapper (false). Build (); / / Global configuration serialization returns JSON processing SimpleModule simpleModule = new SimpleModule () / / JSON Long = = > String simpleModule.addSerializer (Long.class, ToStringSerializer.instance); objectMapper.registerModule (simpleModule); return objectMapper;}}

The little friend put down the phone and cast a look of admiration again. "come on, let's get off work together!" I told my partner that my friend kept asking me all the way how did you study? I said some high-sounding things like how much I want to learn and ask more. In fact, I thought to myself: I am a lazy person, but I can't say. Can lie down never sit, can automatically never manual, can take a taxi never drive. Doing things right the first time is the best way to save time and effort. After so many years of "laziness", I need to think about more "shortcuts". The process of thinking about "shortcuts" is the secret of my continuous progress!

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.