Những kỹ thuật và công nghệ được sử dụng trong sản phẩm Ming.
lượt xem 4
download
Redis là một cách lưu trữ dữ liệu kiểu key/value, nó thực thi trên server ANSI C, redis cung cấp nhiều cách làm việc khác nhau để thực hiện một việc đơn giản : lưu trữ value(“aaa”) tới key(“redis”), trong đó với các keys chỉ hỗ trợ kiểu string thì với values sẽ hỗ trợ nhiều kiểu định dạng khác nhau
Bình luận(0) Đăng nhập để gửi bình luận!
Nội dung Text: Những kỹ thuật và công nghệ được sử dụng trong sản phẩm Ming.
- Những kỹ thuật và công nghệ được sử dụng trong sản phẩm Ming
- 2 Công nghệ Memcached(Đã được sử dụng rộng rãi trong các dự án công ty) Redis(Phần I) Kỹ thuật Open Authentication(Phần II) SSO(Single Sign On) Big4(Facebook, Yahoo, Twitter, Google) I. Redis Redis là một cách lưu trữ dữ liệu kiểu key/value, nó thực thi trên server ANSI C, redis cung cấp nhiều cách làm việc khác nhau để thực hiện một việc đơn giản : lưu trữ value(“aaa”) tới key(“redis”), trong đó với các keys chỉ hỗ trợ kiểu string thì với values sẽ hỗ trợ nhiều kiểu định dạng khác nhau như : Strings, Lists, Sets, Sortedsets(zsets), Hashes. Và mỗi một loại kiểu định dạng khác nhau sẽ có một tập hợp các command làm việc với nó như: Thêm mới, loại bỏ một phần tử trong values... khác nhau. Có thể xem Redis như là một cấu trúc dữ liệu (data structures) cấp cao trên máy server, khi một người dùng redis chỉ cần cung cấp một interface để “Abstract Data Types(kiểu dữ liệu trừu tượng)”, từ đó người dùng không phải chạy các data structures hay các thuật toán trên data structures đó mà có thể thực thi các command của data type đó. Redis is free software released under the very liberal BSD license. Written in C(C99 standard). Redis có những đặc điểm giống như Memcached như: Lưu Key – value (Key – value store). Tất cả data được lưu trên Memory(RAM) Key có thể hết hạn(expire) hoặc không Nhanh(Fast), nhẹ nhàng(light-weight) Nhưng Redis có nhiều đặc điểm, chức năng khác mạng lại lợi ích khi sử dụng và triển khai. Bao gồm: Persistence Multiple databases Team Ming
- 3 Queryable keyspace Support for interger counters Higher level data structures Atomic operations Ability to paginate lists without mutating them Master-slave replication Optional VM feature I.1 So sánh Redis, Memcached, Tokyo Tyrant and MySQL Redis Memcached Tokyo Tyrant / Tokyo Cabinet MySQL 5.1.40 (MyISAM) MySQL 5.1.40 (with Innodb Plugin 1.0.4), compiled into source of MySQL 2 client boxes All clients connecting to the server using Python Used Python's threads to create concurrency Each thread made 10,000 open-close connections to the server The server was o Intel(R) Pentium(R) D CPU 3.00GHz o Fedora 10 32bit o Intel(R) Pentium(R) D CPU 3.00GHz o 2.6.27.38-170.2.113.fc10.i686 #1 SMP o 1GB RAM Used a md5 as key and a value that was saved Created an index on the key column of the table Each server had SET and GET requests as a different test at same concurrency Team Ming
- 4 Team Ming
- 5 I.2. Đăc điểm của Redis I.2.1. Persistence, higher level data structures Redis lấy và nạp dữ liệu trên Memory(RAM), nhưng tại một thời điểm thì dữ liệu có thể được lưu trữ trên disk(Data in memory, but saved on disk). Có 2 kiểu persistence được supported: Semi persistent mode (Snapshotting): Thời gian lưu trữ data trên Memory và Disk là không đồng bộ Team Ming
- 6 Sau mỗi N sự thay đổi hoặc N thời gian nào đó thì data mới được lưu trữ trên disk. Do việc lưu trữ data là không đồng bộ nên data có thể bị mất khi server gặp sự cố(restart or start) Fully persistent mode (Append Only File) Mỗi sự thay đổi được viết thêm vào một tệp tin. Mô hình này được gọi là “Append only file”, mỗi command nhận sự thay đổi thì được viết thêm vào file có định dạng là ASAP. Những command này sẽ được chạy lại khi server restart hoặc start để nạp lại dữ liệu lên memory. I.2.2. Multiple databases và Data structures Điểm khác biệt dễ nhận thấy của Redis là: Key là một string nhưng value thì không giới hạn ở một string mà có thể là List, Sets, Sorted sets, .... Cấu trúc dữ liệu của Redis gồm : Strings String-as-integers List of Strings Set of Strings(unique list) Sorted Set of Strings(ZSET) Redis hỗ trợ “Multiple database” với nhiều commands để tự động remove key từ một database tới database khác. Mặc định thì DB 0 sẽ được lựa chọn cho mỗi lần kết nối(connection), nhưng khi sử dụng lệnh SELECT(SELECT command) thì nó có thể select/create một database khác. Thao tác MOVE(MOVE operation) có thể chuyển một item từ một DB tới DB khác một cách tự động. Đó là sự khác biệt của Redis với Mysql. Với Mysql, để truy suất data từ nhiều database khác nhau thì phải tạo ra bấy nhiêu connection tới những database đó. I.2.3. Atomic Operations Redis rất nhanh trong các thao tác lấy và nạp dữ liệu do redis hỗ trợ nhiều lệnh mang tính chất chuyên biệt như: Team Ming
- 7 LPUSH/PPUSH: Thêm vào đầu/cuối của danh sách. LPOP/RPOP: Return và remove phần tử ở đầu/cuối của danh sách. RPOPLPUSH: Return và remove phần tử cuối của source list và đẩy vào đầu của destination list GETSET: Nạp một key với một giá trị mới và trả về giá trị cũ. MGET/MSET: Lấy/nạp nhiều key với nhiều data. SMOVE: Chuyển một value từ one set to another. ….. Rất nhiều tính năng ưu việt và chuyện biệt nữa được redis hỗ trợ. I.2.4. Replication Redis hỗ trợ mở rộng master-slave nếu chúng ta muốn sự an toàn hoặc mở rộng, co giãn trong việc lưu trữ data. Slaves can be used for scalability or redundancy Một master có thể có nhiều slave Slaves có thể nhận nhiều kết nối của salve khác Slave có thể kết nối lại khi bị outage I.3. Thay thế Memcached hoặc kết hợp Memcached với Redis Redis có thể thay thế được Memcache vì: Những gì memcache làm được thì redis cũng có thể, nhưng redis có nhiều tính năng mà memcache ko thể có được. Many databases from a single instance of Redis Có thể backup dữ liệu trên redis khi server đang hoạt động: Khi Redis lưu DB nó tạo ra một tập tin tạm thời, sau đó đổi tên (2) tên tập tin tạm thời với tên file đích. Có thể sử dụng master-slave để nhân rộng cơ sở dự liệu dự phòng Watch live commands on a running instance with the MONITOR command Có thể sử dụng redis như là một database, queue, server cache hoặc tất cả các kết hợp. Team Ming
- 8 Redis và Memcache đều có ưu nhược điểm riêng, nhưng nếu kết hợp được Redis và Memcache song hành trong công việc thì đó là một điều lý tưởng. I.4. Redis nhanh như thía nào?(How fast is Redis) Redis có tiện tích “redis-benchmark” được thực hiện với bộ mô phỏng gồm N clients trong cùng một thời điểm gửi M yêu cầu. Dưới đây là kết quả của redis-benchmark: 50 Client thực hiện đồng thời với 100.000 request. Thực hiện SET và GET một String có kích thước 256 bytes. About 110.000 SETs per second About 81.000 GETs per second. ====== SET ====== 100.007 requests completed in 0.88 seconds 50 parallel clients 3 bytes payload keep alive: 1 58.50%
- 9 43.12%
- 10 II.3 Đặc tả OAuth 1.0(http://oauth.net/core/1.0/) II.3.1 Các khái niệm service provider - SP: Nơi cung cấp dịch vụ OAuth consumer/app: Bhách hàng sử dụng dịch vụ OAuth user: người dùng request_token: Bộ khóa(key & secret) khở tạo phiên làm việc giữa consumer và SP access_token: Bộ khóa(key & secret) consumer dùng để lấy thông tin(tài nguyên) của người dùng ở SP oauth_key: Khóa định danh oauth_secret: Mã bảo mật consumer_key: Khóa định danh app consumer_secret: Mã bảo mật app callback: Đường dẫn trả về site consumer II.3.2 Luồng sơ lược SP và Consumer thống nhất bộ consumer_key và consumer_secret 1. Consumer – Service Provider Consumer sử dụng định danh consumer gửi yêu cầu lấy request_token tới SP, báo một phiên làm việc bắt đầu. SP kiểm tra định danh consumer, trả lại request_token ngẫu nhiên (oauth_key, oauth_secret). 2. Consumer – user Consumer chuyển người dùng tới trang đăng nhập của SP 3. User - SP User đăng nhập bằng tài khoản của mình ở SP với thông báo cho phép dịch vụ consumer lấy thông tin. Người dùng tiếp theo sẽ được chuyển về trang đợi sẵn của consumer (callback) với mã oauth_verifier(SP sinh ngẫu nhiên) chứng nhận rằng người dùng đã (đăng nhập và) đồng ý chia sẻ thông tin. Team Ming
- 11 4. Consumer-SP Tiếp theo bước 3 thì SP gửi về cho consumer một mã gọi là oauth_verifier để thông báo cho Consumer biết là user đã đăng nhập xong trên SP. Consumer gửi yêu cầu lấy access_token, sử dụng các định danh consumer, request_token và oauth_verifier để chứng thực. Lúc này, consumer sẽ phải gửi lại oauth_verifier để thông báo cho SP là consumer đã nhận được thông báo “user đã đăng nhập trên SP”. SP kiểm tra, trả về cho consumer access_token có sẵn trong hệ thống hoặc tạo mới. 5. Consumer-SP Với các api SP cung cấp, consumer sử dụng bộ thông tin định danh consumer (key và secret) và access_token gửi yêu cầu tới SP lấy thông tin người dung cần thiết. Dưới đây là hình vẽ mô tả luồng OAuth trên: Team Ming
- 12 II.4 OAuth server ở Ming Đã hoàn tất đầy đủ các bước theo đặc tả 1.0 Dễ dàng cho bên thứ ba phát triển consumer Sử dụng công cụ chứng thực an toàn là chữ ký Secret được giữ kín An ninh bảo đảm trên đường non-https Nonce duy nhất ứng với mỗi request kèm theo timestamp, không bị giả mạo request dù xảy ra trường hợp bị xâm nhập trái phép trước đó. Thống nhất quy chuẩn chữ ký, do đặc tả oauth mới phát triển, mỗi thư viện sử dụng có lỗi nhỏ khác nhau: thư viện php mã hóa đường dẫn 2 Team Ming
- 13 lần, thư viện c# thiếu những param định nghĩa thêm… Vấn đề gây nhiều lỗi nhất trong quá trình thực hiện OAuth. “One of the most frustrating things about working with OAuth is getting back an error that the signature is invalid” (http://support.mashery.com/docs/tips_and_tricks/OAuth) “The signature base string is often the most difficult part of OAuth for newcomers to construct.” (http://dev.twitter.com/pages/auth) Xác thực domain Mã xác thực đã đăng nhập SP chỉ trả về trang callback nằm trên domain consumer đã đăng ký. Team Ming
CÓ THỂ BẠN MUỐN DOWNLOAD
-
Tìm hiểu về mô hình của các Hãng kiểm toán quốc tế và lợi ích của các Hãng thành viên
9 p | 283 | 90
-
Thủ thuật của các đại gia trên sàn chứng khoán
3 p | 210 | 87
-
Các dạng biểu đồ trong phân tích kỹ thuật
13 p | 218 | 56
-
Bài giảng Kỹ thuật nghiệp vụ ngoại thương - Nguyễn Hồng Ngọc
125 p | 191 | 46
-
Phân tích chi tiêu công - Chương 4
45 p | 158 | 37
-
Luận văn: Thực tế triển khai các nghiệp vụ bảo hiểm thiết bị điện tử tại công ty cổ phần bảo hiểm bưu điện
87 p | 134 | 31
-
Chiến thuật thăm dò thị trường và mua trung bình tăng
8 p | 152 | 27
-
Huy động và sử dụng hiệu quả vốn đầu tư nước ngoài - 3
6 p | 100 | 17
-
Bắn cung... tìm vốn!
5 p | 120 | 16
-
Điểm khác biệt giữa những nhà đầu tư thành công
8 p | 97 | 14
-
Công ty quản lý quỹ và mục đích tồn tại
3 p | 124 | 12
-
Cải thiện thành tích giao dịch của bạn
13 p | 87 | 12
-
Quá trình hình thành và phương pháp nắm bắt quan điểm tính tất yếu khách quan và con đường hình thành cong ty ở việt nam p1
9 p | 115 | 11
-
Kỹ thuật mua bán Penny Stock
16 p | 116 | 11
-
Quá trình hình thành và phương pháp phát triển khoa học công nghệ có tính quyết định trong sự phát triển quốc gia p3
10 p | 86 | 11
-
Để đàm phán bất động sản thành công
3 p | 125 | 10
-
Giảm giá nhà chung cư: Giải pháp từ kĩ thuật xây dựng
4 p | 72 | 7
Chịu trách nhiệm nội dung:
Nguyễn Công Hà - Giám đốc Công ty TNHH TÀI LIỆU TRỰC TUYẾN VI NA
LIÊN HỆ
Địa chỉ: P402, 54A Nơ Trang Long, Phường 14, Q.Bình Thạnh, TP.HCM
Hotline: 093 303 0098
Email: support@tailieu.vn