Shulou(Shulou.com)05/31 Report--

In this issue, the editor will bring you about what the ORACLE locking mechanism is. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

Http://blog.csdn.net/xujinyang/article/details/6822936

Locks are purely conceptual, but they are very useful. I have sorted out two articles before, and I have read some books today, but I think it is not very clear. So I reorganized it. I was thinking about whether to delete the previous article, which is more brief in blog, but then I thought about it again. These connections may be referenced elsewhere. If you decide to keep it, it can be regarded as a process of witnessing your growth.

I. lock (Lock)

1.1 the concept of locks

The database is a shared resource used by multiple users. When multiple users access data concurrently, multiple transactions will access the same data at the same time in the database. If there is no control over concurrent operations, incorrect data may be read and stored, and the consistency of the database will be destroyed.

Locking is a very important technology to realize database concurrency control. When a transaction makes a request to the system and locks it before operating on a data object. After locking, the transaction has some control over the data object, and other transactions cannot update the data object until the transaction releases the lock.

In the Oracle database, it does not lock a table or several rows, the lock exists as an attribute of the data block. In other words, each data block itself stores the information of the data in its own data block, which is called ITL (Interested Transaction List). If there is an active transaction on this data block, its information will be recorded here for subsequent operations to query, so as to ensure the consistency of the transaction.

1.2 Classification of locks

1.2.1. According to the user and system, it can be divided into automatic lock and display lock.

A) automatic locking (Automatic Locks): when performing a database operation, by default, the system automatically acquires all necessary locks for this database operation. Automatic locking DML lock, DDL lock, system locks.

B) display lock (Manual Data Locks): in some cases, the data used by the user to lock the database operation is required to make the database operation perform better, and the display lock is set by the user for the database object.

Oracle Database performs locking automatically to ensure data concurrency, data integrity, and statement-level read consistency. However, you can manually override the Oracle Database default locking mechanisms. Overriding the default locking is useful in situations such as the following:

Applications require transaction-level read consistency or repeatable reads.

In this case, queries must produce consistent data for the duration of the transaction, not reflecting changes by other transactions. You can achieve transaction-level read consistency by using explicit locking, read-only transactions, serializable transactions, or by overriding default locking.

Applications require that a transaction have exclusive access to a resource so that the transaction does not have to wait for other transactions to complete.

You can override Oracle Database automatic locking at the session or transaction level. At the session level, a session can set the required transaction isolation level with the ALTER SESSION statement. At the transaction level, transactions that include the followingSQL statements override Oracle Database default locking:

(1) The SET TRANSACTION ISOLATION LEVEL statement

(2) The LOCK TABLE statement (which locks either a table or, when used with views, the base tables)

(3) The SELECT... FOR UPDATE statement

Locks acquired by the preceding statements are released after the transaction ends or a rollback to savepoint releases them.

If Oracle Database default locking is overridden at any level, then the database administrator or application developer should ensure that the overriding locking procedures operate correctly. The locking procedures must satisfy the following criteria: data integrity is guaranteed, data concurrency is acceptable, and deadlocks are not possible or are appropriately handled.

1.2.2. According to the lock level, it can be divided into exclusive Exclusive Locks (X lock) and shared lock (Share Locks, S lock).

A) shared lock (S): a shared lock enables one transaction to share access to a specific database resource-another transaction can also access that resource or acquire the same shared lock. Shared locks provide high concurrency for transactions, but poor transaction design + shared locks can easily lead to deadlocks or loss of data updates.

B) exclusive lock (X): after the transaction sets an exclusive lock, the transaction acquires this resource alone, and another transaction cannot acquire the shared or exclusive lock of the same object before the transaction commits.

1.2.3 according to operation, it can be divided into DML lock (data locks, data lock), DDL lock (data dictionary lock) and System Locks.

1.2.3.1 DML lock

DML lock is used to control data manipulation in concurrent transactions to ensure data consistency and integrity. DML locks are mainly used to protect data integrity in concurrent situations. It is divided into:

(1) TM lock (table level lock)

(2) TX lock (transaction lock or row level lock)

When Oracle executes the DML statement, the system automatically applies a lock of type TM on the table to be operated on. When the TM lock is obtained, the system automatically applies for the TX type lock and sets the lock flag bit of the actual locked data row. In this way, when checking the compatibility of the TX lock before the transaction is added, there is no need to check the lock flag line by line, but only to check the compatibility of the TM lock mode, which greatly improves the efficiency of the system.

There is only an X lock (exclusive lock) on the data row. In an Oracle database, when a transaction initiates a DML statement for the first time, it acquires an TX lock that is held until the transaction is committed or rolled back. When two or more sessions execute DML statements on the same record in the table, the first session locks the record and the other sessions wait. When the first session is committed, the TX lock is released so that other sessions can be locked.

When TX lock waiting occurs in Oracle database, if it is not handled in time, it will often cause Oracle database to hang, or lead to deadlock, resulting in ORA-600 error. These phenomena will do great harm to practical applications, such as unresponsive for a long time, a large number of transaction failures and so on.

TM lock (table lock)

When a transaction acquires a row lock, the transaction also automatically acquires the table lock (shared lock) of the row to prevent other transactions from making DDL statements to affect the update of the record row. Transactions can also acquire shared or exclusive locks while in progress, and only when the transaction display defines an exclusive lock as shown in the LOCK TABLE statement will the transaction acquire an exclusive lock on the table, or use the LOCK TABLE display to define a table-level shared lock (see the relevant documentation for the specific use of LOCK TABLE).

The TM lock includes many modes, such as SS, SX, S, X and so on, which is represented by 0Mel 6 in the database. Different SQL operations produce different types of TM locks.

TX lock (row lock)

When a transaction performs database insert, update, and delete operations, the transaction automatically acquires the exclusive lock of the operation rows in the operation table.

For the user's data manipulation, Oracle can automatically lock the manipulated data, but if there is manipulation authorization, additional locking can be implemented to meet the needs of concurrent manipulation. DML locks can be explicitly locked by a user process or implied by some SQL statements. This part belongs to Manual Data Locks.

DML locks can be locked in the following three ways:

(1), shared lock mode (SHARE)

(2), exclusive lock mode (EXCLUSIVE)

(3), shared update lock (SHARE UPDATE)

Where:

SHARE,EXCLUSIVE is used for TM locks (table-level locks)

SHARE UPDATE is used for TX locks (row-level locks).

(1) shared table-level locks (Share)

The shared table-level lock is to lock all the data in the table, which is used to protect the consistency of the query data and prevent other users from updating the locked table. Other users can only impose shared locks on the table, but can no longer impose exclusive locks on the table. Shared update locks can be re-imposed, but processes holding shared update locks are not allowed to update. All users who share the table can only query the data in the table, but cannot update it.

Table-level locks in shared mode can only be set by users with SQL statements. The base statement format is as follows:

LOCK TABLE [,]... IN SHARE MODE [NOWAIT]

Execute this statement to impose a shared table lock on one or more tables. When the option NOWAIT is specified, if the lock cannot be applied successfully for the time being, it is returned and it is up to the user to decide whether to wait or execute another statement first.

A transaction that holds a shared lock releases its shared lock when one of the following conditions occurs:

A. execute COMMIT or ROLLBACK statements.

B. Exit the database (LOG OFF).

C. the program stops running.

Shared-mode table-level locks are often used in the process of consistent query, that is, the data in the table does not change during the query period.

(2) exclusive table-level lock (Exclusive)

The exclusive table level lock is used to lock all the data in the table, and the user who has the exclusive mode table lock can query the table and update the table. Other users can no longer impose any locks on the table (including shared, exclusive, or shared update locking). Although other users cannot update the table, they can query the table.

Table locking in an exclusive manner can be obtained explicitly through the following SQL statement:

LOCK TABLE [,].... IN EXCLUSIVE MODE [NOWAIT]

Exclusive table-level locks can also be implicitly acquired when the user executes DML statements INSERT, UPDATE, and DELETE.

Transactions that have an exclusive mode table blockade will release the blockade when one of the following conditions occurs:

(1) execute COMMIT or ROLLBACK statements.

(2) exit the database (LOG OFF)

(3) the program stops running.

Exclusive locking is usually used to update data, reducing deadlocks when an update transaction involves multiple tables.

(3) shared update locking method (Share Update)

Shared update locking is to lock one or more rows of a table, so it is also called row-level locking. Although table-level locking ensures the consistency of data, it weakens the parallelism of operational data. Row-level locking ensures that it is not modified by other users during the time that the user gets the updated row to the row for update. Therefore, row-level locking can not only ensure the consistency of data, but also improve the burst of data operation.

Row-level blockade can be achieved in two ways:

(1) execute the following SQL blocking statement to get it as shown:

LOCK TABLE [,].... IN SHARE UPDATE MODE [NOWAIT]

(2) use the following SELECT... FOR UPDATE statement to obtain:

SELECT [,]... FROM WHERE FOR UPDATE OF [,]. [NOWAIT]

Once a user imposes a row-level lock on a row, the user can query or update the locked data row, while other users can only query but not update the locked data row. if other users want to update rows in the table, they must also impose row-level locks on the table. even if multiple users use shared updates on a table, two transactions are not allowed to update the same table at the same time. When you actually update a table, you lock the table exclusively until the transaction is committed or restored. Row locks are always exclusive locks.

Release the shared update lock when one of the following conditions occurs:

(1) execute the COMMIT statement

(2) exit the database (LOG OFF)

(3) the program stops running.

The row lock cannot be released by performing a ROLLBACK operation.

1.2.3.2 DDL Lock (dictionary locks)

DDL locks are used to protect the structure of database objects, such as tables, indexes, and so on.

DDL lock can be divided into exclusive DDL lock, shared DDL lock and analysis lock.

(1) exclusive DDL lock:

Create, modify, and delete the DDL statement of a database object to obtain the exclusive lock of the Operand object. For example, when using alter table statements, the transaction acquires a row of DDL locks in order to maintain the completeness, consistency, and legitimacy of the data.

(2) shared DDL lock:

DDL statements that need to establish interdependencies between database objects usually need to share DDL locks. If you create a package in which procedures and functions reference different database tables, when the package is compiled, the transaction acquires a shared DDL lock for the referenced table.

(3) Analysis lock:

ORACLE uses shared pools to store analyzed and optimized SQL statements and PL/SQL programs to make applications running the same statements faster. An object cached in a shared pool acquires the parse lock of the database object it references. The parse lock is a unique type of DDL lock that ORACLE uses to track dependencies between shared pool objects and the database objects it references. When a transaction modifies or deletes a database object in the shared pool that holds an analysis lock, ORACLE invalidates the object in the shared pool, and the next time the SQL/PLSQL statement is referenced, ORACLE reparses and compiles the statement.

DDL-level locking is also controlled by ORACLE RDBMS, which is used to protect consistency and integrity when data dictionaries and data definitions are changed. It is that the system automatically adds locks when parsing SQL definition statements without user intervention.

Dictionary / parsing locking is divided into three categories:

(1) Dictionary operation lock:

Used to lock data dictionaries when operating on dictionaries, this blockade is exclusive, thus protecting that only one dictionary can be operated on at any one time.

(2) Dictionary definition locks:

Used to prevent parsing during dictionary operations, so as to avoid changing the structure of a table while querying the dictionary.

(3) Table definition lock:

Used by a SQL statement to prevent items in the dictionary related to a table from being modified when it accesses the table.

Automatic Locks in DDL Operations

Http://download.oracle.com/docs/cd/E11882_01/server.112/e10592/ap_locks002.htm#SQLRF55509

A data dictionary (DDL) lock protects the definition of a schema object while an ongoing DDL operation acts on or refers to the object. Only individual schema objects that are modified or referenced are locked during DDL operations. The database never locks the whole data dictionary.

Oracle Database acquires a DDL lock automatically on behalf of any DDL transaction requiring it. Users cannot explicitly request DDL locks. For example, if a user creates a stored procedure, then Oracle Database automatically acquires DDL locks for all schema objects referenced in the procedure definition. The DDL locks prevent these objects from being altered or dropped before procedure compilation is complete.

Exclusive DDL Locks

An exclusive DDL lock prevents other sessions from obtaining a DDL or DML lock. Most DDL operations, except for those described in "Share DDL Locks", require exclusive DDL locks for a resource to prevent destructive interference with other DDL operations that might modify or reference the same schema object. For example, DROP TABLE is not allowed to drop a table while ALTER TABLE is adding a column to it, and vice versa.

Exclusive DDL locks last for the duration of DDL statement execution and automatic commit. During the acquisition of an exclusive DDL lock, if another DDL lock is already held on the schema object by another operation, then the acquisition waits until the older DDL lock is released and then proceeds.

Share DDL Locks

A share DDL lock for a resource prevents destructive interference with conflicting DDL operations, but allows data concurrency for similar DDL operations.

For example, when a CREATE PROCEDURE statement is run, the containing transaction acquires share DDL locks for all referenced tables. Other transactions can concurrently create procedures that reference the same tables and acquire concurrent share DDL locks on the same tables, but no transaction can acquire an exclusive DDL lock on any referenced table.

A share DDL lock lasts for the duration of DDL statement execution and automatic commit. Thus, a transaction holding a share DDL lock is guaranteed that the definition of the referenced schema object remains constant during the transaction.

Breakable Parse Locks

A parse lock is held by a SQL statement or PL/SQL program unit for each schema object that it references. Parse locks are acquired so that the associated shared SQL area can be invalidated if a referenced object is altered or dropped. A parse lock is called a breakable parse lock because it does not disallow any DDL operation and can be broken to allow conflicting DDL operations.

A parse lock is acquired in the shared pool during the parse phase of SQL statement execution. The lock is held as long as the shared SQL area for that statement remains in the shared pool.

1.2.3.2 System Locks

System Locks

Http://download.oracle.com/docs/cd/E11882_01/server.112/e10713/consist.htm#CIHJBIBB

Oracle Database uses various types of system locks to protect internal database and memory structures. These mechanisms are inaccessible to users because users have no control over their occurrence or duration.

Latches

Latches are simple, low-level serialization mechanisms that coordinate multiuser access to shared data structures, objects, and files. Latches protect shared memory resources from corruption when accessed by multiple processes. Specifically, latches protect data structures from the following situations:

(1) Concurrent modification by multiple sessions

(2) Being read by one session while being modified by another session

(3) Deallocation (aging out) of memory while being accessed

Typically, a single latch protects multiple objects in the SGA. For example, background processes such as DBWn and LGWR allocate memory from the shared poolto create data structures. To allocate this memory, these processes use a shared pool latch that serializes access to prevent two processes from trying to inspect or modify the shared pool simultaneously. After the memory is allocated, other processes may need to access shared pool areas such as the library cache, which is required for parsing. In this case, processes latch only the library cache, not the entire shared pool.

Unlike enqueue latches such as row locks, latches do not permit sessions to queue. When a latch becomes available, the first session to request the latch obtains exclusive access to it. Latch spinning occurs when a process repeatedly requests a latch in a loop, whereas latch sleeping occurs when a process releases the CPU before renewing the latch request.

Typically, an Oracle process acquires a latch for an extremely short time while manipulating or looking ata data structure. For example, while processing a salary update of a single employee, the database may obtain and release thousands of latches. The implementation of latches is operating system-dependent, especially in respect to whether and how long a process waits for a latch.

An increase in latching means a decrease in concurrency. For example, excessive hard parse operations create contention for the library cache latch. TheV$LATCH view contains detailed latch usage statistics for each latch, including the number of times each latch was requested and waited for.

Mutexes

A mutual exclusion object (mutex) is a low-level mechanism that prevents an object in memory from aging out or from being corrupted when accessed by concurrent processes. A mutex is similar to a latch, but whereas a latch typically protects a group of objects, a mutex protects a single object.

Mutexes provide several benefits:

(1) A mutex can reduce the possibility of contention.

Because a latch protects multiple objects, it can become a bottleneck when processes attempt to access any of these objects concurrently. By serializing access to an individual object rather than a group, a mutex increases availability.

(2) A mutex consumes less memory than a latch.

(3) When in shared mode, a mutex permits concurrent reference by multiple sessions.

Internal Locks

Internal locks are higher-level, more complex mechanisms than latches and mutexes and serve various purposes. The database uses the following types of internal locks:

(1) Dictionary cache locks

These locks are of very short duration and are held on entries in dictionary caches while the entries are being modified or used. They guarantee that statements being parsed do not see inconsistent object definitions. Dictionary cache locks can be shared or exclusive. Shared locks are released when the parse is complete, whereas exclusive locks are released when the DDL operation is complete.

(2) File and log management locks

These locks protect various files. For example, an internal lock protects the control file so that only one process at a time can change it. Another lock coordinates the use and archiving of the online redo log files. Data files are locked to ensure that multiple instances mount a database in shared mode or that one instance mounts it in exclusive mode. Because file and log locks indicate the status of files, these locks are necessarily held for a long time.

(3) Tablespace and undo segment locks

These locks protect tablespaces and undo segments. For example, all instances accessing a database must agree on whether a tablespace is online or offline. Undo segments are locked so that only one database instance can write to a segment.

II. Latch and waiting

Latch belongs to System Locks. In the previous content, there has been a relevant explanation. Latch is a resource invented by Oracle to protect memory structure.

In Oracle's complex memory structure, such as SGA, all kinds of data are repeatedly read from disk to memory and then rewritten back to disk. If concurrent users do the same thing, Oracle must use a mechanism to ensure that data can only be read by one session. This protection mechanism is Latch.

Concurrency: means that more than two users make changes to the same data (which may include inserts, deletions, and modifications).

Parallel: it means to divide a thing into many small parts, let each part be executed at the same time, and finally summarize the execution results into the final result.

Latch can be thought of as a lightweight lock, which does not cause blocking, but only leads to waiting. Blocking is a problem of system design, and waiting is a problem of contention of system resources.

If you find that Lock often causes users to wait in the system, you need to consider whether there are problems in the logical design of the system, such as multi-user deletion or modification of primary keys, whether users use select. Syntax like for update is a factor in whether foreign keys create indexes or not. These factors need to be combined with the business logic of the system to design database objects.

If it is found that the system is slow because of a lot of Latch contention, it is necessary to consider whether there are problems in the design of the system and database itself, such as whether to use bound variables, whether there is thermal fast, whether the design of data storage parameters is reasonable and so on.

There are many reasons for waiting for Latch contention, and there may be contention for many resources in memory. The two most common types of latch contention are as follows:

(1) Latch contention in the shared pool.

(2) latch contention in the data buffer pool.

Detailed description of Oracle memory architecture

Http://blog.csdn.net/xujinyang/article/details/6829522

2.1 Latch contention in shared pool

If there is a large amount of SQL in the shared pool that is repeatedly analyzed, it will cause a lot of Latch contention and long waiting. the most common phenomenon is that there are no bound variables.

The most common Latch in a centralized shared pool is library cache. You can query it through SQL: select * from v$latchname where name like 'library cache%'

When analyzing system performance, if you see Latch contention such as library cache, you can conclude that there is a problem in the shared pool, which is basically caused by SQL statements, such as no bound variables or some stored procedures are repeatedly analyzed.

2.2 data buffer pool Latch contention

Frequently accessed data blocks are called Hot Block. When many users access certain data blocks together, it will lead to some Latch contention. The most common latch contention is:

(1) buffer busy waits

(2) cache buffer chain

The contention between the two Latch occurs at different times when the data block is accessed.

33 common wait events in Oracle

Http://blog.csdn.net/xujinyang/article/details/6882035

When a session needs to access a memory block, it first goes to a structure like a linked list to search whether the data block is in memory. When the session accesses the linked list, it needs to get a Latch. If the acquisition fails, Latch cache buffer chain wait will occur. The reason for this wait is that there are too many sessions accessing the same data block or the list is too long (if you read too much data in memory. The hash list that needs to manage the data block will be very long, so the session scanning list time will increase, the chache buffer chain latch holding time will be longer, the chances of other sessions getting this Latch will be reduced, and the wait will increase.

When a session needs to access a block of data that is being read from disk to memory by another user or is being modified by another session, the current session needs to wait, resulting in a buffer busy waits wait.

The direct cause of these Latch contention is the hot fast problem caused by too many sessions accessing the same data block, which may be caused by database settings or repeated SQL frequently accessing some of the same data blocks.

The causes of thermal fast are different. According to the type of data block, it can be divided into several types. Different thermal fast types are handled in different ways, as follows:

(1) Table data block

(2) Index data block

(3) Index root data block

(4) header data block

2.2.1 Table data block

For example, in the OLTP system, for some small tables, some data blocks will be frequently queried or modified. At this time, these frequently accessed data blocks will become hot blocks, resulting in memory Latch contention.

If such a hot block occurs and the table is not too large, one way is to consider distributing the table data over more data blocks to reduce the frequency of data blocks being accessed by most sessions at the same time.

You can minimize the number of records stored in each block with the following command: Alter table minimize records_per_block

We distribute the data to more data blocks, which greatly reduces the probability of a data block being read repeatedly. However, the obvious disadvantage of this approach is that it degrades the performance of the data, in which case, accessing the same data means that more data blocks need to be read, and the performance will be degraded.

2.2.2 indexed data blocks

Such a situation usually occurs in a RAC architecture, where the index key values of a table show a typical "right-leaning" phenomenon. For example, the primary key of a table uses a sequence to generate key values, then the key values of the primary key on the index data block are arranged in an increasing order, such as: 1, 2, 3, 4, 5. Because these keys are very closely distributed, when many users insert a primary key into a table in different instances of RAC, the same index data block will be called in the memory of different instances, creating a data block contention. In this case, the use of reverse index can alleviate this contention. Reverse index is the former index key values are arranged in the reverse way, in the normal primary key B-Tree index, the key values will be arranged in order of size, such as: 1234, reverse index, the key value will become 4321.

In this way, the key values that were originally placed on the same index data block are now distributed on different data blocks, so that the primary key values inserted by users on different instances of RAC will not lead to hot blocks because they are distributed on different data blocks, which is basically the only case in which the reverse index is used.

The use of reverse indexing is so limited because it discards one of the most important functions of B-Tree indexes: Index range scan.

In the index access mode, Index range scan is the most common, but the reverse index can not use this function, because the reverse index has messed up the order of key values, when looking for a range according to the order of key values, these values are no longer stored continuously in the reverse index because the key values are stored in reverse. So the Index range scan approach doesn't make any sense in reverse indexing. In reverse indexing, it can only be achieved by full table scan or full index scan. This is a very serious flaw in reverse indexing.

2.2.3 Index root data block

Hot blocks can also occur on the root block of the index. In an B-Tree index, when Oracle accesses an index key value, it first accesses the root of the index, then the branch of the index, and finally the leaf block of the index. The key value of the index is stored on the leaf block. As shown in the figure:

When the root and branch data of the index are concentrated on several data blocks, such as the branch data block where DMagol G is located, this data block will be accessed when the range of user access is from Amurf. If many users access the index key values of this range frequently, it may cause this branch data block to become hot fast.

When this phenomenon occurs, you can consider partitioning the index to facilitate the use of these roots, branch data blocks are distributed to different data segments (partitions), so as to reduce the density of parallel access of data blocks, so as to avoid the index root. Hot blocks are generated due to the concentration of branch data blocks.

2.2.4 Section header data block

Before Oracle 9i, the space usage of data blocks needed to be managed manually, and there were one or more Free list lists at the head of each segment to store which blocks in the segment could be used.

When the data of the block reaches a percentage of the total capacity of the block (determined by the PCT_FREE parameter), the block is deleted from the Free list and the block can no longer be inserted.

When the space of the data block is reduced to a proportion (determined by the PCT_USED parameter), the data block is placed in the Free list list, and these databases can be used to insert data.

In the OLTP system, the Free List of some data segments may be a frequently accessed data block, for example, there are many delete and insert actions on some tables on this database, and many sessions need to constantly access the Free List list of these data blocks in order to get the required block information. At this point, the data block (called the segment header data block) becomes a hot block, and Latch wait events such as cacha buffer chain appear in memory.

When this problem occurs, a common solution is to increase the number of Free List to spread the density of data blocks accessed by the session.

Starting with Oracle 9i, an automatic segment management technology, ASSM (Automatic Segment Space Management: ASSM), is introduced, which allows Oracle to manage "Free List" automatically. In fact, there is no such structure as Free List in ASSM. Oracle uses bitmaps to mark the availability of data blocks, which is more efficient than using a list to manage data blocks.

For the OLTP system, the DML operation of the table is very intensive. For these tables, the use of ASSM management will be more convenient and accurate than manual management, and can effectively prevent the segment head from becoming a hot block.

For the OLAP system, this parameter does not have much practical significance, because in such a database, few tables are frequently modified, and the main work of the OLAP system is the batch loading of reports and massive data.

This is what the ORACLE lock mechanism shared by the editor is like. If you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

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.