6 datacenters running the same mysql database, replication layout design question
20 commits/second is not very fast.

A Master can have any number of Slaves.  Those Slaves can be local to the same datacenter or remote, in the other datacenters.

You can have "relay" servers that act like a Slave to the Master, but then act like a Master to 'downstream' Slaves.  With this kind of topology, you can have an unlimited number of Slaves.  (I have not seen it more than 3 level deep including the Master.  Nor have I seen more than a few dozen Slaves total.  But no "limit" was being hit.)

Multiple Masters is a much different matter.  Usually the best topology is to have two Masters, one being written to and the other being a hot backup.  This is "Dual Master, single writer".  Each of them can have Slave(s).

Even better is Galera Clustering -- See MariaDB or Percona (PXC).  It allows for 3 or more writable masters and handles most of the nasties that led me to say "single writer" in the previous paragraph.  Again, these "nodes" can have "Slave(s)" hanging off them.

Keep in mind that a Slave can only be read from.  To "write" you need to hit a Master.  If the master is on the "other side of the country (or world)", there are speed-of-light delays, upwards of 100ms to go across the US.

The delays do not necessarily impact the "20 commits/sec".  At 100ms, you cannot perform more than 10 commits/sec from a single connection.  But, you probably have multiple connections, correct?

At 100 commits/sec, some disk tuning issues come into play.  At 1000/sec, other issues raise their ugly heads.  Some carefully crafted benchmarks have run at 1M/sec.

You have not explained what you mean by "ID consistency".  One thing comes to mind:  When writing to both Masters in a Dual-Master setup, you are asking for this kind of trouble.