Apakah penyelesaian untuk ID yang diedarkan redis?
Penyelesaian ID teragih yang biasa digunakan
Dalam sistem teragih, adalah sangat penting untuk menjana ID unik di peringkat global, kerana dalam sistem teragih, Berbilang nod menjana ID pada masa yang sama boleh menyebabkan konflik ID.
Berikut memperkenalkan beberapa penyelesaian ID teragih yang biasa digunakan.
UUID
UUID (Universally Unique Identifier) adalah pengecam yang terdiri daripada 128 digit, yang boleh menjamin keunikan global kerana algoritma penjanaannya adalah berdasarkan cap waktu, ID nod dan faktor lain. UUID boleh dijana menggunakan kelas UUID yang disertakan dengan Java, seperti yang ditunjukkan di bawah:
javaCopy code import java.util.UUID; public class UuidGenerator { public static void main(String[] args) { UUID uuid = UUID.randomUUID(); System.out.println(uuid.toString()); } }
Kelas UUID yang disertakan dengan Java sangat mudah dan mudah digunakan, serta tidak memerlukan konfigurasi dan pengurusan tambahan kelebihannya. Oleh kerana panjangnya (128 bit), UUID tidak sesuai sebagai kunci utama untuk jadual pangkalan data dan sukar untuk diisih dan diindeks.
Snowflake
Snowflake ialah algoritma penjanaan ID yang diedarkan sumber terbuka oleh Twitter Ia boleh menjana ID unik 64-bit, yang mengandungi maklumat seperti cap waktu, ID pusat data dan ID mesin. Kod Java bagi algoritma Snowflake adalah seperti berikut:
Kod Java bagi algoritma Snowflake:
javaCopy code public class SnowflakeGenerator { private final static long START_STMP = 1480166465631L; private final static long SEQUENCE_BIT = 12; private final static long MACHINE_BIT = 5; private final static long DATACENTER_BIT = 5; private final static long MAX_DATACENTER_NUM = -1L ^ (-1L << DATACENTER_BIT); private final static long MAX_MACHINE_NUM = -1L ^ (-1L << MACHINE_BIT); private final static long MAX_SEQUENCE = -1L ^ (-1L << SEQUENCE_BIT); private final static long MACHINE_LEFT = SEQUENCE_BIT; private final static long DATACENTER_LEFT = SEQUENCE_BIT + MACHINE_BIT; private final static long TIMESTMP_LEFT = DATACENTER_LEFT + DATACENTER_BIT; private long datacenterId; private long machineId; private long sequence = 0L; private long lastStmp = -1L; public SnowflakeGenerator(long datacenterId, long machineId) { if (datacenterId > MAX_DATACENTER_NUM || datacenterId < 0) { throw new IllegalArgumentException("datacenterId can't be greater than MAX_DATACENTER_NUM or less than 0"); } if (machineId > MAX_MACHINE_NUM || machineId < 0) { throw new IllegalArgumentException("machineId can't be greater than MAX_MACHINE_NUM or less than 0"); } this.datacenterId = datacenterId; this.machineId = machineId; } public synchronized long nextId() { long currStmp = getNewstmp(); if (currStmp < lastStmp) { throw new RuntimeException("Clock moved backwards. Refusing to generate id"); } if (currStmp == lastStmp) { sequence = (sequence + 1) & MAX_SEQUENCE; if (sequence == 0L) { currStmp = getNextMill(); } } else { sequence = 0L; } lastStmp = currStmp; return (currStmp - START_STMP) << TIMESTMP_LEFT | datacenterId << DATACENTER_LEFT | machineId << MACHINE_LEFT | sequence; } private long getNextMill() { long mill = getNewstmp(); while (mill <= lastStmp) { mill = getNewstmp(); } return mill; } private long getNewstmp() { return System.currentTimeMillis(); } }
Kelebihan algoritma Snowflake ialah prestasi tinggi dalam menjana ID dan panjang ID pendek (64 bits), yang boleh Sebagai kunci utama jadual pangkalan data, ia memudahkan pengisihan dan pengindeksan. Walau bagaimanapun, perlu diingat bahawa jika bilangan nod dalam kluster melebihi bilangan digit yang diduduki oleh ID mesin, atau kluster sangat besar dan bilangan digit cap masa tidak mencukupi, maka algoritma penjanaan ID teragih lain perlu dipertimbangkan.
Leaf
Leaf ialah algoritma penjanaan ID teragih sumber terbuka oleh Meituan Dianping Ia boleh menjana ID 64-bit yang unik secara global. Kod Java bagi algoritma Leaf adalah seperti berikut:
Kod Java bagi algoritma Leaf:
javaCopy code public class LeafGenerator { private static final Logger logger = LoggerFactory.getLogger(LeafGenerator.class); private static final String WORKER_ID_KEY = "leaf.worker.id"; private static final String PORT_KEY = "leaf.port"; private static final int DEFAULT_PORT = 8080; private static final int DEFAULT_WORKER_ID = 0; private static final int WORKER_ID_BITS = 10; private static final int SEQUENCE_BITS = 12; private static final int MAX_WORKER_ID = (1 << WORKER_ID_BITS) - 1; private static final int MAX_SEQUENCE = (1 << SEQUENCE_BITS) - 1; private static final long EPOCH = 1514736000000L; private final SnowflakeIdWorker idWorker; public LeafGenerator() { int workerId = SystemPropertyUtil.getInt(WORKER_ID_KEY, DEFAULT_WORKER_ID); int port = SystemPropertyUtil.getInt(PORT_KEY, DEFAULT_PORT); this.idWorker = new SnowflakeIdWorker(workerId, port); logger.info("Initialized LeafGenerator with workerId={}, port={}", workerId, port); } public long nextId() { return idWorker.nextId(); } private static class SnowflakeIdWorker { private final long workerId; private final long port; private long sequence = 0L; private long lastTimestamp = -1L; SnowflakeIdWorker(long workerId, long port) { if (workerId < 0 || workerId > MAX_WORKER_ID) { throw new IllegalArgumentException(String.format("workerId must be between %d and %d", 0, MAX_WORKER_ID)); } this.workerId = workerId; this.port = port; } synchronized long nextId() { long timestamp = System.currentTimeMillis(); if (timestamp < lastTimestamp) { throw new RuntimeException("Clock moved backwards. Refusing to generate id"); } if (timestamp == lastTimestamp) { sequence = (sequence + 1) & MAX_SEQUENCE; if (sequence == 0L) { timestamp = tilNextMillis(lastTimestamp); } } else { sequence = 0L; } lastTimestamp = timestamp; return ((timestamp - EPOCH) << (WORKER_ID_BITS + SEQUENCE_BITS)) | (workerId << SEQUENCE_BITS) | sequence; } private long tilNextMillis(long lastTimestamp) { long timestamp = System.currentTimeMillis(); while (timestamp <= lastTimestamp) { timestamp = System.currentTimeMillis(); } return timestamp; } } }
Walaupun algoritma Leaf menjana ID perlahan sedikit daripada algoritma Snowflake, ia boleh menyokong lebih ramai pekerja nod . ID yang dijana oleh algoritma Leaf terdiri daripada tiga bahagian, iaitu cap waktu, ID Pekerja dan nombor siri Cap masa menduduki 42 bit, ID Pekerja menduduki 10 bit, dan nombor siri menduduki 12 bit, dengan jumlah 64 bit.
Yang di atas adalah algoritma penjanaan ID teragih biasa Sudah tentu, terdapat penyelesaian lain, seperti: ID MongoDB, UUID, Twitter Snowflake, dll. Penyelesaian yang berbeza sesuai untuk senario perniagaan yang berbeza, dan butiran pelaksanaan dan prestasi khusus juga berbeza Anda perlu memilih penyelesaian yang sesuai berdasarkan situasi sebenar.
Selain algoritma penjanaan ID teragih yang diperkenalkan di atas, terdapat juga beberapa penyelesaian penjanaan ID teragih baharu muncul, seperti algoritma penjanaan ID teragih Flicker, yang menggunakan idea serupa dengan Snowflake, tetapi menggunakan kaedah peruntukan bit yang berbeza ialah lebih fleksibel daripada Snowflake, dan bilangan bit yang diduduki oleh setiap bahagian boleh dilaraskan secara dinamik mengikut keperluan. Selain itu, Facebook turut melancarkan penyelesaian Perkhidmatan Penjanaan ID (IGS), yang memisahkan penjanaan dan storan ID, menyediakan penyelesaian yang lebih fleksibel dan berskala, tetapi memerlukan reka bentuk dan pelaksanaan seni bina yang lebih kompleks.
Mengikut keperluan perniagaan yang berbeza, berbilang set penyelesaian penjanaan ID yang diedarkan boleh direka bentuk. Berikut ialah beberapa cadangan peribadi saya:
Penjanaan berdasarkan ID autokenaikan pangkalan data: Menggunakan ID autokenaikan pangkalan data sebagai ID unik di peringkat global boleh memastikan keunikan ID dan mudah untuk melaksanakan , tetapi konkurensi yang tinggi boleh menyebabkan kesesakan prestasi. Oleh itu, tidak disyorkan untuk menggunakannya dalam senario konkurensi tinggi.
Jana berdasarkan UUID: Menggunakan UUID sebagai ID unik secara global boleh menjamin keunikan ID, tetapi panjang ID adalah panjang (128 bit), yang tidak sesuai untuk penyimpanan dan penghantaran, dan Kebarangkalian ID pendua adalah sangat kecil tetapi bukan 0. Adalah disyorkan bahawa apabila menggunakan sistem teragih, panjang ID dan kos penyimpanan dan penghantaran perlu dipertimbangkan.
Dijana berdasarkan Redis: Menggunakan operasi atom Redis, keunikan ID boleh dijamin, dan kelajuan penjanaan ID adalah sangat pantas, yang boleh digunakan pada senario konkurensi tinggi . Perlu diingat bahawa jika Redis ranap atau berprestasi buruk, ia boleh menjejaskan kecekapan dan ketersediaan penjanaan ID.
Dijana berdasarkan ZooKeeper: Menggunakan penjana nombor siri ZooKeeper boleh memastikan keunikan ID, dan pelaksanaannya agak mudah, tetapi ia memerlukan pengenalan kebergantungan dan sumber tambahan, dan terdapat mungkin masalah prestasi tersekat.
Untuk memilih penyelesaian penjanaan ID yang diedarkan yang sesuai dengan senario perniagaan anda, anda perlu mempertimbangkan secara menyeluruh berbilang faktor seperti keunikan ID, kelajuan penjanaan, panjang, kos penyimpanan, kebolehskalaan dan ketersediaan. Melaksanakan penyelesaian yang berbeza memerlukan mempertimbangkan pertukaran dan pilihan dalam situasi sebenar, kerana butiran pelaksanaan dan prestasinya juga berbeza.
Demo kod terperinci setiap penyelesaian diberikan di bawah:
Jana berdasarkan ID kenaikan automatik pangkalan data
javaCopy code public class IdGenerator { private static final String JDBC_URL = "jdbc:mysql://localhost:3306/test"; private static final String JDBC_USER = "root"; private static final String JDBC_PASSWORD = "password"; public long generateId() { Connection conn = null; PreparedStatement pstmt = null; ResultSet rs = null; try { Class.forName("com.mysql.jdbc.Driver"); conn = DriverManager.getConnection(JDBC_URL, JDBC_USER, JDBC_PASSWORD); pstmt = conn.prepareStatement("INSERT INTO id_generator (stub) VALUES (null)", Statement.RETURN_GENERATED_KEYS); pstmt.executeUpdate(); rs = pstmt.getGeneratedKeys(); if (rs.next()) { return rs.getLong(1); } } catch (Exception e) { e.printStackTrace(); } finally { try { if (rs != null) { rs.close(); } if (pstmt != null) { pstmt.close(); } if (conn != null) { conn.close(); } } catch (Exception e) { e.printStackTrace(); } } return 0L; } }
Jana berdasarkan UUID
javaCopy code import java.util.UUID; public class IdGenerator { public String generateId() { return UUID.randomUUID().toString().replace("-", ""); } }
Jana berdasarkan Redis
javaCopy code import redis.clients.jedis.Jedis; public class IdGenerator { private static final String REDIS_HOST = "localhost"; private static final int REDIS_PORT = 6379; private static final String REDIS_PASSWORD = "password"; private static final int ID_GENERATOR_EXPIRE_SECONDS = 3600; private static final String ID_GENERATOR_KEY = "id_generator"; public long generateId() { Jedis jedis = null; try { jedis = new Jedis(REDIS_HOST, REDIS_PORT); jedis.auth(REDIS_PASSWORD); long id = jedis.incr(ID_GENERATOR_KEY); jedis.expire(ID_GENERATOR_KEY, ID_GENERATOR_EXPIRE_SECONDS); return id; } catch (Exception e) { e.printStackTrace(); } finally { if (jedis != null) { jedis.close(); } } return 0L; } }
Dihasilkan berdasarkan ZooKeeper
javaCopy code import java.util.concurrent.CountDownLatch; import org.apache.zookeeper.CreateMode; import org.apache.zookeeper.WatchedEvent; import org.apache.zookeeper.Watcher; import org.apache.zookeeper.ZooDefs.Ids; import org.apache.zookeeper.ZooKeeper; public class IdGenerator implements Watcher { private static final String ZK_HOST = "localhost"; private static final int ZK_PORT = 2181; private static final int SESSION_TIMEOUT = 5000; private static final String ID_GENERATOR_NODE = "/id_generator"; private static final int ID_GENERATOR_EXPIRE_SECONDS = 3600; private long workerId = 0; public IdGenerator() { try { ZooKeeper zk = new ZooKeeper(ZK_HOST + ":" + ZK_PORT, SESSION_TIMEOUT, this); CountDownLatch latch = new CountDownLatch(1); latch.await(); if (zk.exists(ID_GENERATOR_NODE, false) == null) { zk.create(ID_GENERATOR_NODE, null, Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT); } workerId = zk.getChildren(ID_GENERATOR_NODE, false).size(); zk.create(ID_GENERATOR_NODE + "/worker_" + workerId, null, Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL); } catch (Exception e) { e.printStackTrace(); } } public long generateId() { ZooKeeper zk = null; try { zk = new ZooKeeper(ZK_HOST + ":" + ZK_PORT, SESSION_TIMEOUT, null); CountDownLatch latch = new CountDownLatch(1); latch.await(); zk.create(ID_GENERATOR_NODE + "/id_", null, Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL, (rc, path, ctx, name) -> {}, null); byte[] data = zk.getData(ID_GENERATOR_NODE + "/worker_" + workerId, false, null); long id = Long.parseLong(new String(data)) * 10000 + zk.getChildren(ID_GENERATOR_NODE, false).size(); return id; } catch (Exception e) { e.printStackTrace(); } finally { if (zk != null) { try { zk.close(); } catch (Exception e) { e.printStackTrace(); } } } return 0L; } @Override public void process(WatchedEvent event) { if (event.getState() == Event.KeeperState.SyncConnected) { System.out.println("Connected to ZooKeeper"); CountDownLatch latch = new CountDownLatch(1); latch.countDown(); } } }
Perhatikan bahawa nod sementara ZooKeeper digunakan di sini untuk menyelaraskan setiap nod pekerja Jika nod pekerja ditutup, nod sementaranya juga akan dipadamkan. Ini boleh Memastikan bahawa ID yang diperoleh oleh setiap nod pekerja adalah unik.
Atas ialah kandungan terperinci Apakah penyelesaian untuk ID yang diedarkan redis?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!

Alat AI Hot

Undresser.AI Undress
Apl berkuasa AI untuk mencipta foto bogel yang realistik

AI Clothes Remover
Alat AI dalam talian untuk mengeluarkan pakaian daripada foto.

Undress AI Tool
Gambar buka pakaian secara percuma

Clothoff.io
Penyingkiran pakaian AI

Video Face Swap
Tukar muka dalam mana-mana video dengan mudah menggunakan alat tukar muka AI percuma kami!

Artikel Panas

Alat panas

Notepad++7.3.1
Editor kod yang mudah digunakan dan percuma

SublimeText3 versi Cina
Versi Cina, sangat mudah digunakan

Hantar Studio 13.0.1
Persekitaran pembangunan bersepadu PHP yang berkuasa

Dreamweaver CS6
Alat pembangunan web visual

SublimeText3 versi Mac
Perisian penyuntingan kod peringkat Tuhan (SublimeText3)

Topik panas











Mod Redis cluster menyebarkan contoh Redis ke pelbagai pelayan melalui sharding, meningkatkan skalabilitas dan ketersediaan. Langkah -langkah pembinaan adalah seperti berikut: Buat contoh Redis ganjil dengan pelabuhan yang berbeza; Buat 3 contoh sentinel, memantau contoh redis dan failover; Konfigurasi fail konfigurasi sentinel, tambahkan pemantauan maklumat contoh dan tetapan failover; Konfigurasi fail konfigurasi contoh Redis, aktifkan mod kluster dan tentukan laluan fail maklumat kluster; Buat fail nodes.conf, yang mengandungi maklumat setiap contoh Redis; Mulakan kluster, laksanakan perintah Buat untuk membuat kluster dan tentukan bilangan replika; Log masuk ke kluster untuk melaksanakan perintah maklumat kluster untuk mengesahkan status kluster; buat

Cara Mengosongkan Data Redis: Gunakan perintah Flushall untuk membersihkan semua nilai utama. Gunakan perintah flushdb untuk membersihkan nilai utama pangkalan data yang dipilih sekarang. Gunakan Pilih untuk menukar pangkalan data, dan kemudian gunakan FlushDB untuk membersihkan pelbagai pangkalan data. Gunakan perintah DEL untuk memadam kunci tertentu. Gunakan alat REDIS-CLI untuk membersihkan data.

Untuk membaca giliran dari Redis, anda perlu mendapatkan nama giliran, membaca unsur -unsur menggunakan arahan LPOP, dan memproses barisan kosong. Langkah-langkah khusus adalah seperti berikut: Dapatkan nama giliran: Namakannya dengan awalan "giliran:" seperti "giliran: my-queue". Gunakan arahan LPOP: Keluarkan elemen dari kepala barisan dan kembalikan nilainya, seperti LPOP Queue: My-Queue. Memproses Baris kosong: Jika barisan kosong, LPOP mengembalikan nihil, dan anda boleh menyemak sama ada barisan wujud sebelum membaca elemen.

Pada sistem CentOS, anda boleh mengehadkan masa pelaksanaan skrip LUA dengan mengubah fail konfigurasi REDIS atau menggunakan arahan REDIS untuk mengelakkan skrip jahat daripada memakan terlalu banyak sumber. Kaedah 1: Ubah suai fail konfigurasi Redis dan cari fail konfigurasi Redis: Fail konfigurasi Redis biasanya terletak di /etc/redis/redis.conf. Edit Fail Konfigurasi: Buka fail konfigurasi menggunakan editor teks (seperti Vi atau nano): sudovi/etc/redis/redis.conf Tetapkan had masa pelaksanaan skrip lua: Tambah atau ubah suai baris berikut dalam fail konfigurasi untuk menetapkan masa pelaksanaan maksimum skrip lua (unit: milidor)

Gunakan alat baris perintah redis (redis-cli) untuk mengurus dan mengendalikan redis melalui langkah-langkah berikut: Sambungkan ke pelayan, tentukan alamat dan port. Hantar arahan ke pelayan menggunakan nama arahan dan parameter. Gunakan arahan bantuan untuk melihat maklumat bantuan untuk arahan tertentu. Gunakan perintah berhenti untuk keluar dari alat baris arahan.

Kaunter Redis adalah satu mekanisme yang menggunakan penyimpanan pasangan nilai utama REDIS untuk melaksanakan operasi pengiraan, termasuk langkah-langkah berikut: mewujudkan kekunci kaunter, meningkatkan tuduhan, mengurangkan tuduhan, menetapkan semula, dan mendapatkan tuduhan. Kelebihan kaunter Redis termasuk kelajuan cepat, konkurensi tinggi, ketahanan dan kesederhanaan dan kemudahan penggunaan. Ia boleh digunakan dalam senario seperti pengiraan akses pengguna, penjejakan metrik masa nyata, skor permainan dan kedudukan, dan pengiraan pemprosesan pesanan.

Terdapat dua jenis strategi tamat tempoh data REDIS: Penghapusan berkala: Imbasan berkala untuk memadamkan kunci yang telah tamat tempoh, yang boleh ditetapkan melalui parameter-cap-cap-rempah yang telah tamat tempoh dan parameter kelewatan-cap-remove-time-time. Penghapusan Lazy: Periksa kekunci yang telah tamat tempoh hanya apabila kunci dibaca atau ditulis. Mereka boleh ditetapkan melalui parameter lazon-lazy-expire-expire-expire, lazy-lazy-user-del parameter.

Dalam sistem Debian, panggilan sistem Readdir digunakan untuk membaca kandungan direktori. Jika prestasinya tidak baik, cuba strategi pengoptimuman berikut: Memudahkan bilangan fail direktori: Split direktori besar ke dalam pelbagai direktori kecil sebanyak mungkin, mengurangkan bilangan item yang diproses setiap panggilan readdir. Dayakan Caching Kandungan Direktori: Bina mekanisme cache, kemas kini cache secara teratur atau apabila kandungan direktori berubah, dan mengurangkan panggilan kerap ke Readdir. Cafh memori (seperti memcached atau redis) atau cache tempatan (seperti fail atau pangkalan data) boleh dipertimbangkan. Mengamalkan struktur data yang cekap: Sekiranya anda melaksanakan traversal direktori sendiri, pilih struktur data yang lebih cekap (seperti jadual hash dan bukannya carian linear) untuk menyimpan dan mengakses maklumat direktori
